Bind storage credential authority to recorded node incarnations #321

Credential vending reconstructs storage authority from current placement, snapshot source, and the latest execution's node name. These paths resolve the candidate logical node through today's node_k8s UID. A same-name replacement can therefore inherit historical candidates even though TokenReview authenticates its replacement identity.

Follow up separately from #283's Begin/Finalize policy:

• Check recorded execution incarnation on active and target placement; preserve explicit authority for legitimate restore destinations.
• Match snapshot-source authority to the attempt's recorded source UID, including retries, failed attempts, and legacy unknown identity.
• Compare the latest execution's recorded UID rather than joining its name alone.
• Define scope and rollout for old rows and both deployment orders. Do not backfill historical UIDs from the current registry.
• Add synthetic replacement, relocation/restore, retry, stale-registry, and unknown-identity tests at the credential boundary. Also track propagating verified caller node identity through internal API authentication rather than relying on its address.

The additive execution and per-attempt UID fields in #283's prerequisite stack provide evidence for this work; they do not change credential vending by themselves. Owning code: crates/libs/credential/mgr/server/src/storage_vend_store.rs, crates/libs/credential/mgr/server/src/auth.rs, and the common/internal API authentication boundary.

AI assistance: Codex drafted this follow-up from source review.