COSE signatures becomes a map (was singleton value)

[Max (maxtropets)]

Another step towards #7848.

• This time, COSE signatures tables becomes ServiceValue -> ServiceMap.
• Although it's technically public facing change, it's neither blocking or needs advertising, therefore no changelog yet
  • service_value_singleton=0 remains CLASSICAL signature
  • we don't sign PQ yet
• For all existing purposes, only CLASSICAL value is expected and treated as mandatory (yet)

[Copilot]

🟡 Changes recommended

There are a couple of correctness hazards (notably an assertion that can fire on removal-only writes and legacy signature selection returning empty signatures) that should be addressed before approval.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR advances the work towards #7848 by changing the COSE signatures KV table from a singleton ServiceValue to a ServiceMap keyed by IdentityType, enabling multiple concurrent signing identities (currently still using CLASSICAL only) while preserving legacy serialisation compatibility.

Changes:

• Convert COSE_SIGNATURES from ServiceValue<CoseSignature> to ServiceMap<IdentityType, CoseSignature>, and propagate the new CoseSignatureMap through receipts, snapshotting, and signature caching.
• Update historical query/receipt description logic to select the CLASSICAL COSE signature for legacy v1 APIs.
• Add/extend unit tests and update audit documentation to reflect the new map shape and semantics.

Custom instructions used:

• /.github/copilot-instructions.md
• /.github/instructions/reviewing.instructions.md

File summaries

File	Description
src/service/tables/signatures.h	Converts COSE signatures table to a map keyed by IdentityType and adds extraction helper.
src/service/tables/identity_types.h	Defines IdentityType and its blit serialiser to preserve legacy singleton key encoding.
src/node/tx_receipt_impl.h	Changes receipt storage from optional single COSE signature to a per-identity signature map.
src/node/signature_cache_interface.h	Updates cached signature interface to carry a CoseSignatureMap.
src/node/signature_cache_subsystem.h	Updates commit hooks/caching logic to collect COSE signature writes as a map.
src/node/snapshotter.h	Threads COSE signatures as a map through snapshot persistence flow.
src/node/snapshot_serdes.h	Builds snapshot receipts using the COSE signatures map.
src/node/history.h	Writes COSE signatures keyed by IdentityType::CLASSICAL and reads per-key previous write version.
src/node/historical_queries.h	Fetches COSE signatures as a map and selects CLASSICAL for legacy description paths.
src/node/historical_queries_adapter.cpp	Updates v1 receipt description to return CLASSICAL signature from the map.
src/node/rpc/node_frontend.h	Updates receipt endpoint path to read CLASSICAL COSE signature from the map.
src/node/node_state.h	Updates internal COSE signature reads and snapshotter hook to use extracted map writes.
src/endpoints/endpoint_registry.cpp	Constructs receipts using cached COSE signature maps.
src/node/test/snapshotter.cpp	Updates snapshotter test to record COSE signatures as a map.
src/node/test/history.cpp	Adds round-trip/compatibility/unit tests for the COSE signature map and extraction helper.
src/node/test/historical_queries.cpp	Adds tests validating cached vs historical COSE signature transaction alignment and CLASSICAL selection.
doc/audit/builtin_maps.rst	Updates documentation for cose_signatures key/value semantics as an identity-keyed map.

Review details

• Files reviewed: 16/16 changed files
• Comments generated: 4
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[cjen1-msft]

I think this is fine.

Some testing says that consumers who could try to pull in the "public:ccf.internal.cose_signatures" table will be fine as the sentinel value maps over.
And then they can be migrated later.
Similarly for JS.

The only risk is if someone pulled the signatures alias from the private headers somehow.

[Max (maxtropets)]

The only risk is if someone pulled the signatures alias from the private headers somehow.

Users will be meant to pull those when they are filled up. They aren't now, and won't be until 8.x on AL4, but by then we'll have all the necessary things in.

This step is mainly preparatory work, and should not affect KV at all (from the user's perspective).