ML-DSA signatures in CCF

@maxtropets is already working on this.

Since Sep 1, 2026.

An attempt to https://github.com/microsoft/CCF/discussions/7971 (ledger signing part).

This's an ☔ for subtasks/PRs, to keep track of PQ signing completion in general.

------------------

**Why?**
* As we want PQ update to be a live code update, and as we want identities rotation flexibility, there's a separate ticket to solve that: #8264.
* This ticket focuses on supporting multiple signing identities for new or DR-ed services.

**Structural changes planned in this one**
- [x] New MLDSA PKI interface and impl (#8378)
- [x] Identity schema changes (#8263, #8304)
- current service identity serves as TLS identity, it's no longer back-endorsed
- signing identities are stored separately
- public parts: in the new table
- private parts: in node's memory
- [x] COSE signatures schema change (#8334)
- CLASSICAL=0 == ServiceKeySingleton for backwards compatibility
- PQ=1 - new value
- [ ] Back endorsements
- Schema changes (per identity type) (#8401)
- Big change to endorsement chain handling, same KV change as for signatures
- Separately, when recovering from a snapshot, a different endorsement handling mechanism is in use, needs handling different endorsement types
- [ ] Endpoints/interfaces to serve signing keys for external/internal use cases, currently TBD

**Workflow change**
- On fresh network start or recovery, the identity choice is determined by the config
- Signing identities are distributed alongside the existing service TLS identity on Join request, always in sync (until rotation is solved)
- Removing identity type is currently prohibited, as in CLASSICAL+PQ to a single is disallowed
- allows to have a realistic scope of changes, and keep endorsement chain contract
- later on, we can come up with identity termination, but there's no plan for such a need rn, as HYBRID signing is what we're aiming for the foreseeable future