Transactional cert slot update #306

What

A slot update writes several objects: the certificate file, the CRL file, and the slot descriptor. Trust-store changes add the trust-store descriptor. Each write is atomic on its own, but nothing makes the set atomic. A failure or crash between writes can leave a combination that never existed. Examples: a new certificate with the old CRL, a certificate stored while its member state is not persisted, or on PKCS#11 an empty slot after a failed create.

The fix is to never overwrite content the current manifest references. Each part of a slot (certificate, CRL) gets two sides, A and B. An update writes the inactive side in full, then makes one descriptor write that flips the selectors of every part that changed. The previous side stays as backup. The public API does not change.

Acceptance Criteria (DoD)

• A failure at any step (certificate side, CRL side, manifest write) leaves the slot as it was before the update.
• A reader never reads a side the manifest does not reference.
• A certificate and its CRL committed together are visible together or not at all.
• Concurrent reads during a commit see one consistent generation.
• Startup validates the manifest and the referenced sides against their recorded hashes. A mismatch makes the slot unusable and is reported, without exposing filesystem paths to clients.
• IntegrityPolicy::kRequired is enforced: the recorded hash is compared on load.
• A trust-store change that activates several exclusive members is visible as a whole, or not at all.

How

No response