fix(admin): retire the query-string form of immediate KMS key deletion

Immediate deletion destroys master key material outright, and every
object encrypted under that key becomes permanently unreadable. The
delete endpoint accepted that request as a query parameter, which is the
form most easily issued by accident and the one that made the waiting
window bypassable.

The query string can now only schedule a deletion: `force_immediate`
with any value other than `false`, or a `confirm_key_id` parameter, is
refused with 400 rather than downgraded to a scheduled deletion, so a
caller cannot read the answer as "destroyed". The JSON body form is
unchanged and remains the single way to reach the service gate that
enforces the server opt-in and the echoed confirmation.

Classify the route accordingly: `RouteRiskLevel` gains `Critical` for
routes whose worst case is permanent loss of user data, and the KMS key
deletion route is the only member, pinned in both directions by a matrix
test. Endpoint-level coverage for the 7-30 day window bound is added for
every configured backend.

Refs rustfs/backlog#1585 (part of rustfs/backlog#1562)

crates/security-governance/src/admin_matrix.rs

@@ -63,6 +63,14 @@ pub enum RouteRiskLevel {
     Normal,
     Sensitive,
     High,
+    /// A single authorized request can destroy stored data beyond every
+    /// recovery path the server offers — no undo, no waiting window, no
+    /// backup taken on the caller's behalf.
+    ///
+    /// This is deliberately narrower than [`Self::High`], which covers routes
+    /// that change state an operator can put back. Reserve it for routes whose
+    /// worst case is permanent loss of user data.
+    Critical,
 }
 
 #[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]