feat(rc-admin)!: add secure RustFS KMS configuration lifecycle

[cxymds]

Related issues

Resolves rustfs/backlog#1396
Part of rustfs/backlog#1378
Roadmap: rustfs/backlog#1361

Background

RustFS beta.10 supports dynamic KMS configuration and service control, but configuration contains Local master keys or Vault credentials. Accepting those values as command-line literals or reflecting server bodies into diagnostics would expose secrets through process listings, shell history, logs, or structured output.

This PR is stacked on #279 so configuration lifecycle remains independently reviewable.

Solution

• add rc admin kms configure ALIAS --config-file PATH|--stdin
• add rc admin kms reconfigure ALIAS --config-file PATH|--stdin
• add KMS start, confirmed restart --yes, and confirmed stop --yes
• validate strict Local, VaultKV2, and VaultTransit beta.10 request shapes before network access
• enforce a 1 MiB input bound
• on Unix, require a regular non-symlink configuration file with no group/other permission bits and verify device/inode stability across open
• reject Vault URL credentials, query parameters, fragments, insecure production transport, and development tokens outside explicit development mode
• preserve beta.10 reconfiguration semantics: an empty Token may reuse the stored token, while partial AppRole credentials are always rejected
• add typed output-v3 lifecycle results and stable permission, unsupported, unavailable, rejected, malformed, and usage failures
• add core, signed transport, CLI integration, schema, parser, and documentation coverage

Security

No configuration secret is accepted through a field-specific command-line option or positional JSON. Raw input, typed secret fields, serialized request bytes, HTTP request ownership, response text, response messages, and service-status values use zeroizing application-owned storage. Non-success response bodies are not read into diagnostics, and all client-facing errors are static and value-free.

On non-Unix platforms, Unix mode-bit enforcement is unavailable; stdin should come from a protected pipe or secret manager.

Compatibility

BREAKING contract marker: this extends the protected CLI reference and output-v3 KMS contract with configuration and service lifecycle operations. Existing output-v1 and output-v2 contracts remain unchanged.

Validation

• cargo fmt --all --check
• cargo clippy --workspace --all-targets -- -D warnings
• cargo test --workspace
• core KMS tests: 6 passed
• S3 KMS tests: 14 passed
• CLI KMS configuration integration tests: 7 passed

All checks pass locally. Native route and request contracts are covered with signed mock Admin servers; a live configured RustFS KMS environment is still recommended before merge. HTTP and serde dependencies may make transient internal copies outside application-owned zeroizing buffers.

[cxymds]

Validation is complete for head ef0a92b38dc1931226093a2bf45379224ed72c79.

• CI: passed, including Windows tests and builds
• Integration Tests: passed
• Local: cargo fmt --all --check, cargo clippy --workspace --all-targets -- -D warnings, and cargo test --workspace passed

The earlier Windows-only test-fixture failure used a Unix absolute path in a platform-neutral core test. Commit ef0a92b now constructs the Local KMS test path with the platform temp directory; production validation behavior is unchanged. The PR base is restored to cxymds/issue-1395-kms-key-lifecycle.