…r378 backport] (#3948)

## Summary

**Backport of the #3944 fix to the `master378` (1.5.378) maintenance
branch.** See the 2.0 PR #3947 for the primary change; this PR applies
the equivalent fix to the 1.5.378 code.

The stack did not verify that **CA/issuer certificates** in a chain
assert the KeyUsage required for a CA. Per **OPC 10000-6 §6.2.4, Table
52**, a CA certificate must carry a KeyUsage extension asserting
`keyCertSign` and `cRLSign`, and **OPC 10000-4 §6.1.3, Table 100
("Certificate Usage")** requires validators to check issuer usage and
report `Bad_CertificateIssuerUseNotAllowed`.

The validator only checked the **leaf** certificate's KeyUsage and
delegated issuer/CA usage to .NET `X509Chain`, which (RFC 5280 §4.2.1.3)
does **not** reject a CA whose KeyUsage extension is *absent* — so a CA
with no KeyUsage was accepted while strict third-party stacks reject the
chain with `BadCertificateInvalid`.

## Changes

- `X509Utils.HasRequiredIssuerKeyUsage(X509Certificate2)` — returns
whether both `keyCertSign` and `cRLSign` are asserted (absent KeyUsage →
`None` → fails).
- `CertificateValidator.InternalValidateAsync` — after the leaf KeyUsage
check, verifies every issuer/CA certificate in the chain and appends a
**suppressible** `Bad_CertificateIssuerUseNotAllowed` when the required
bits are missing.
- **Two coupled defects fixed in `CheckChainStatus`**:
1. A `FormatException` from a named-placeholder format string
(`{Status}: {Information}` → positional `{0}: {1}`) that crashed
validation on any `NotValidForUsage` chain status.
2. An inverted `isIssuer` status-code ternary (issuer↔leaf codes
swapped, contrary to Part 4 Table 100).
- `Docs/Certificates.md` — new "CA (issuer) KeyUsage validation"
subsection.

Every new check/helper carries an in-code citation to the governing spec
sections.

## Testing

- New tests in `CertificateValidatorTest.cs` (matching the branch's
existing style: `X509Certificate2`, classic asserts, throwing contract,
event-based approver): a deterministic helper unit test plus reject /
suppress / accept integration tests.
- Full `CertificateValidator` fixture green on **net8.0** and **net48**,
no regressions.

## Compatibility

- This is long-standing behaviour on both `master` and `master378` — not
a 2.0 regression. No public API change; the new error is suppressible.

Relates to #3944 · 2.0 PR: #3947

## Summary

Follow-up to #3948 (merged) that fixes a **macOS-only** CI failure
introduced by the issuer/CA KeyUsage tests.

On the macOS Core test job, three tests failed with:

```
Interop+AppleCrypto+AppleCommonCryptoCryptographicException : Unknown format in import.
   at System.Security.Cryptography.X509Certificates.X509Pal.AppleX509Pal.GetCertContentType(...)
   at System.Security.Cryptography.X509Certificates.X509CertificateLoader.LoadCertificate(...)
```

The affected tests built a test CA with an **empty** KeyUsage extension
(`new X509KeyUsageExtension(X509KeyUsageFlags.None, true)` → a zero-bit
`BIT STRING`). Windows (CryptoAPI) and Linux (OpenSSL) load such a
certificate, but macOS (AppleCrypto) rejects it as an unknown format.
The production code is unaffected — this is purely a test-certificate
artifact.

## Changes

- Removed the degenerate empty-KeyUsage test certificate. The
**truly-absent** KeyUsage case (built via `CertificateRequest` so no
KeyUsage extension is emitted) already covers the `GetKeyUsage() ==
None` code path.
- The reject/suppress integration tests now use a
present-but-insufficient `DigitalSignature` KeyUsage (a valid,
macOS-loadable certificate that is still missing
`keyCertSign`/`cRLSign`).

## Testing

- `CertificateValidator` IssuerKeyUsage tests pass on **Windows** and
**Linux** (net10.0). The change directly removes the macOS root cause
(the empty-KeyUsage extension); all remaining test certificates use
standard formats that macOS already loads (the compliant-CA test passed
on macOS).

Relates to #3944 · follow-up to #3948

…nition only. (#3843)" (#3976)

This reverts commit 00519fa.

# Description

Due to longer investigation time needed on ModelCompiler the pruning of
the extra decoded children that should stay on the type definition only
is reverted

## Related Issues

_Reference all GitHub issues this PR addresses. If there is no issue
yet, open one and link it here._

_If this is a relatively large or complex change, a design must have
been discussed in the related tracking issue and signed off (which
becomes the Architectural Decision Record (ADR))._

- Fixes #github-issue-number, ...

## Checklist

_Put an `x` in the boxes that apply. You can complete these step by step
after opening the PR._

- [ ] I have signed the
[CLA](https://opcfoundation.org/license/cla/ContributorLicenseAgreementv1.0.pdf)
and read the
[CONTRIBUTING](https://github.com/OPCFoundation/UA-.NETStandard/blob/master/CONTRIBUTING.md)
doc.
- [ ] I have added tests that prove my fix is effective or that my
feature works and increased code coverage.
- [ ] I have added all necessary documentation.
- [ ] I have verified that my changes do not introduce (new) build or
analyzer warnings.
- [ ] I ran **all** tests locally using the **UA.slnx** solution against
at least .net **framework** and .net **10**, and all passed.
- [ ] I fixed **all** failing and flaky tests in the CI pipelines and
**all** CodeQL warnings.
- [ ] I have addressed **all** PR feedback received.