feat(kms): add backend capability discovery

Add BackendCapabilities and a KmsBackend::capabilities() method with a
conservative default so callers can discover which lifecycle operations
the active backend supports instead of probing them. Each backend
declares its real matrix (Vault Transit is the only one advertising
version-retaining rotation). Introduce the typed
KmsError::UnsupportedCapability variant for later use by lifecycle
endpoints.

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

crates/kms/src/backends/local.rs

@@ -14,7 +14,7 @@
 
 //! Local file-based KMS backend implementation
 
-use crate::backends::{BackendInfo, KmsBackend, KmsClient};
+use crate::backends::{BackendCapabilities, BackendInfo, KmsBackend, KmsClient};
 use crate::config::KmsConfig;
 use crate::config::LocalConfig;
 use crate::encryption::{AesDekCrypto, DataKeyEnvelope, DekCrypto, generate_key_material};
@@ -1492,6 +1492,17 @@ impl KmsBackend for LocalKmsBackend {
     async fn health_check(&self) -> Result<bool> {
         self.client.health_check().await.map(|_| true)
     }
+
+    fn capabilities(&self) -> BackendCapabilities {
+        // Rotation stays unadvertised until historical key versions can be
+        // retained (see LocalKmsClient::rotate_key); without version history
+        // there is also no versioning capability. Deletion deadlines are not
+        // yet persisted across restarts, but scheduling itself is supported.
+        BackendCapabilities::minimal()
+            .with_enable_disable(true)
+            .with_schedule_deletion(true)
+            .with_physical_delete(true)
+    }
 }
 
 #[cfg(test)]