refactor(kms): drop the dead duplicate api_types::DeleteKeyRequest (#5601)

api_types carried a second DeleteKeyRequest that nothing referenced: it is
absent from the lib.rs re-export list, so rustfs_kms::DeleteKeyRequest has
always resolved to types::DeleteKeyRequest through `pub use types::*`, and
the admin handler builds the real type via `use rustfs_kms::types::*`.

The copy had also drifted apart from the type it shadowed. It still called
force_immediate "for development/testing only" and described the 7-30 day
window as advisory, and it never gained the confirm_key_id field that the
immediate-deletion gate now requires. A caller that reached into api_types
and deserialized into it would silently drop confirm_key_id.

api_types::DeleteKeyResponse stays: it is live, pinned by the
kms_management_responses_have_stable_json_shapes snapshot alongside the
list/describe/cancel response shapes, and it mirrors the admin wire
response rather than duplicating types::DeleteKeyResponse, whose fields
differ. Its doc comment now records why no request twin sits beside it.

crates/kms/src/api_types.rs

@@ -1343,18 +1343,11 @@ pub struct CreateKeyResponse {
     pub key_metadata: KeyMetadata,
 }
 
-/// Request to delete a key
+/// JSON shape returned by the admin delete-key endpoint.
-#[derive(Debug, Clone, Serialize, Deserialize)]
+///
-pub struct DeleteKeyRequest {
+/// The delete *request* shape lives in [`crate::types::DeleteKeyRequest`] —
-    /// Key ID to delete
+/// there is deliberately no copy here, because the immediate-deletion gate
-    pub key_id: String,
+/// (`force_immediate` + `confirm_key_id`) must have exactly one definition.
-    /// Number of days to wait before deletion (7-30 days, optional)
-    pub pending_window_in_days: Option<u32>,
-    /// Force immediate deletion (for development/testing only)
-    pub force_immediate: Option<bool>,
-}
-
-/// Response from delete key operation
 #[derive(Debug, Clone, Serialize, Deserialize)]
 pub struct DeleteKeyResponse {
     /// Success flag