Feature request: default bucket encryption in the Tenant CRD #284

Problem

spec.buckets[] can declare versioning, Object Lock, policies and lifecycle (including transitions after #279), but not default server-side encryption. Setting it still takes an imperative step after the Tenant is ready, e.g. a Job running rc bucket encryption set <alias>/<bucket> --mode sse-s3. With tiers (#280) and transitions (#279) in the CRD, that is the last step that keeps us running a setup Job next to a Tenant.

Proposal

buckets:
  - name: main
    encryption:
      mode: SSE-S3          # or SSE-KMS
  - name: archive
    encryption:
      mode: SSE-KMS
      kmsKeyId: archive-key # optional; RustFS default KMS key when omitted
  - name: legacy
    encryption:
      state: Absent         # remove an operator-owned configuration

• mode: SSE-S3 → PutBucketEncryption with AES256; mode: SSE-KMS → aws:kms with optional KMSMasterKeyID.
• Same ownership rules as objectLockConfiguration and lifecycle: omission leaves the live configuration unmanaged, a matching live configuration is adopted without a write, a different one is replaced or removed only if its hash matches the last configuration the operator recorded in status; otherwise the bucket reports a conflict.
• SSE-KMS requires spec.encryption.enabled, so the operator rejects it up front instead of retrying RustFS's 500 KMS service not initialized.
• Default encryption only affects objects written after it is set; nothing is re-encrypted.

RustFS behaviour this relies on (1.0.2-preview.2)

• GET ?encryption without a configuration returns 400 ServerSideEncryptionConfigurationNotFoundError, not 404.
• The GET body has no XML namespace.
• PUT with aws:kms and no key ID stores the default KMS key, so GET returns a KMSMasterKeyID that was not sent.
• DELETE encryption is idempotent (204 on a missing configuration).