feat(admin): emit KMS management audit events (#5554)

* feat(s3-types): add KMS service-control audit events

Configuration changes and service start/stop are management-plane actions
with no event name of their own, so they could not reach the audit
pipeline at all. Append three variants for them, following the existing
rule that KMS events are audit-only and live outside the `s3:` namespace,
so no bucket notification selector can expand to them.

* feat(admin): audit KMS management operations

Every KMS admin endpoint now builds an OperationContext from the
authenticated caller and hands it to the KMS layer, so the record the
manager already produces carries the principal, source address and
canonical request id instead of the internal placeholder.

A new adapter maps those records onto the server's existing AuditEntry
format and installs itself as the KMS audit sink at service assembly, so
KMS activity reaches the targets a deployment already operates. The
handlers emit directly for what the KMS layer cannot see: a request the
authorization gate rejects, and the endpoints with no context-aware KMS
entry point (data-key derivation and service control).

Only the failure class is recorded, never the error message, and the new
module joins the logging guardrail's checked files alongside the handlers
it serves.

scripts/check_logging_guardrails.sh

@@ -14,7 +14,10 @@ checked_files=(
   "rustfs/src/admin/router.rs"
   "rustfs/src/admin/handlers/table_catalog.rs"
   "rustfs/src/admin/handlers/service_account.rs"
+  "rustfs/src/admin/handlers/kms_audit.rs"
   "rustfs/src/admin/handlers/kms_dynamic.rs"
+  "rustfs/src/admin/handlers/kms_keys.rs"
+  "rustfs/src/admin/handlers/kms_key_lifecycle.rs"
   "rustfs/src/admin/handlers/site_replication.rs"
   "rustfs/src/admin/handlers/group.rs"
   "rustfs/src/admin/handlers/quota.rs"