[reatang]

Summary

KMS key destruction is becoming an explicit two-step operation in rustfs/rustfs#9337: force_immediate only destroys a key that is already PendingDeletion, and a confirmed immediate request against a key that was never scheduled is refused with 400 and changes nothing.

KMS-208's positive path sent one confirmed immediate request against a fresh key and expected 200. It now:

1. sends the confirmed immediate request against the unscheduled key and expects 400, with the key still usable and not pending;
2. schedules the deletion (pending_window_in_days: 7) and expects 200;
3. sends the confirmed immediate request again and expects 200;
4. describes the key and expects 404.

The two refusal checks at the start of the case (query-string form, missing confirm_key_id) are unchanged. KMS-207 is unchanged: the configuration-reference check runs before the key state is looked at, so it still gets the reference refusal.

Merge order

Draft until rustfs/rustfs#9337 is merged. Step 1 fails against any server without that change: the Local backend destroys the key and returns 200, and the Vault backends return 200 after only scheduling it. Steps 2–4 pass on servers with and without the change.

Verification

• bash -n rustfs-kms-test.sh, python3 -m unittest test_rustfs_kms_presign.py, bash test_validation_kms.sh: pass.
• The suite itself was not run; it needs the remote test nodes and a packaged server build. The same request sequence was run by hand against a server built from the fix(kms): require a scheduled deletion before destroying a key rustfs#9337 branch on the Local, Vault KV2 and Vault Transit backends and gave 400, 200, 200, 404.