Logically deletes a key (soft delete). Sets status to DELETED_LOGICAL.

⚠ BREAKING CHANGE: This endpoint now enforces a two-gate policy:

Gate 1 — State: The key MUST be in PENDING_DESTRUCTION state.
Direct deletion from ACTIVE, REVOKED, ARCHIVED or any other state returns 409, and the
detail of that 409 names the steps that remain for the state the key is actually in
— three from ACTIVE, two from REVOKED, one from ARCHIVED. It is derived from the same
transition table the gates enforce, so it cannot name a step the server would refuse.
This description deliberately publishes no fixed sequence: the one it used to publish
(archive first) was wrong from ACTIVE, because archive admits only REVOKED keys.

Gate 2 — Temporal: The cooling-off period established by mark-for-destruction
MUST have elapsed. Deletion before destructionEligibleFrom returns 412
Precondition Failed with the eligible date in the response body.

This design (Model B) enforces compliance retention without requiring a
background scheduler. When a scheduler is added, it calls this same endpoint.

Authorization: requires scope admin.keys.remove.