Verify downloaded snapshots through service identity endorsements

[cjen1-msft]

Allow joining nodes to verify downloaded COSE snapshots signed by earlier service identities, provided a valid endorsement chain connects the signer to the configured current service certificate.

The snapshot download path previously required the snapshot signer to match join_config.service_cert directly. An already-open service may still serve a snapshot from before recovery, even though it has endorsed the signing identity.

Add a SnapshotRead-gated GET /node/snapshot/{snapshot_name}/endorsements endpoint returning base64-encoded COSE endorsements, newest first. Joiners request it only when direct COSE verification fails to match the configured identity. They verify every link, service-epoch continuity, snapshot and receipt epoch coverage, and the snapshot signature/body binding before writing or installing the snapshot. Chain length and byte sizes are bounded.

Directly signed snapshots retain their existing path. Legacy JSON receipts remain direct-certificate-only. Snapshot bytes and range responses are unchanged; backup fetching is unchanged. Recovery-time fallback to another snapshot or ledger replay is intentionally out of scope.

Related to #8043. This is separate from the recovery-infrastructure changes.

Debug logging and snapshotter_test builds pass. The snapshotter unit tests, existing local recovery endorsement scenario, new join scenarios after one and two recoveries, generated OpenAPI schema, and existing snapshot download/failure scenarios pass. scripts/ci-checks.sh passes.

Documentation build was attempted with nix shell nixpkgs#doxygen --command build-debug/env/bin/sphinx-build --fail-on-warning -b html doc doc/html. Doxygen 1.17.0 aborts on the existing ccf::pal::ccf::ds::Mutex alias before Sphinx processes the documentation. A full documentation build remains outstanding.