Talk to radosgw directly via go-ceph + aws-sdk-go-v2

The operator drove the Ceph manager dashboard REST API to manage RGW users,
buckets and policies. That coupled it to a dashboard login, the dashboard's RGW
wiring, and the dashboard's bucket API surface. Rebuild the Ceph integration to
talk directly to radosgw the way the CLI does, using native Go libraries, while
keeping every operator capability identical.

The exported surface of internal/ceph is unchanged, so the three controllers
and cmd/operator's structure are untouched (bar the CEPH_RGW_* config plumbing).

- replace the internal/ceph client internals with github.com/ceph/go-ceph
  rgw/admin (Admin Ops API) for users, keys, quotas and bucket info/removal
- add github.com/aws/aws-sdk-go-v2 S3 client for bucket create, versioning,
  policy, tagging and object lock, signed as the bucket owner
- map go-ceph admin.ErrNoSuch*/ErrUserExists and smithy APIError codes into
  IsNotFound/IsConflict so controller create-vs-update branching is preserved
- set S3 path-style addressing and WhenRequired checksum modes for RGW
- delete the hand-rolled dashboard client, token auth and JSON plumbing
- keep policy.go/BuildBucketPolicy/BuildTagJSON as pure builders
- replace the client tests with NewClient validation and error-classifier tests
- keep CGO_ENABLED=0 distroless: only go-ceph's pure-Go rgw/admin is imported
- switch env/config to CEPH_RGW_* (endpoint, admin endpoint, access/secret key,
  region, CA, insecure) and update the deployment manifest
- rewrite README and docs/ceph-setup.md for the single RGW admin user
  (caps users=*;buckets=*), keeping Vault/VSO as the primary credential source

Claude-Session: https://claude.ai/code/session_016CEncETbf8cvy1PhsHfFHM

docs/ceph-setup.md

@@ -105,7 +105,35 @@ deployment sources from a Secret named **`cephrgw-credentials`** in its namespac
 > At least one of `CEPH_RGW_ENDPOINT` or `CEPH_RGW_ADMIN_ENDPOINT` must be set —
 > the API endpoint falls back to `CEPH_RGW_ENDPOINT` when the admin one is unset.
 
-Create it directly:
+### Primary method: Vault + VSO
+
+The Secret is not managed in GitOps; it is rendered from Vault by the Vault
+Secrets Operator (VSO). The argocd-apps `cephrgw-system` app ships a `VaultAuth`
+and a `VaultStaticSecret` that authenticate with the shared `default` Kubernetes
+auth role and render the KV path
+`kubernetes/namespace/cephrgw-system/default/cephrgw-credentials` into the
+`cephrgw-credentials` Secret. That path sits under the cluster's templated
+default policy (`kv/data/kubernetes/namespace/<ns>/<sa>/*`), so **no dedicated
+Vault role or policy is required** — you only seed the values:
+
+```bash
+vault kv put kv/kubernetes/namespace/cephrgw-system/default/cephrgw-credentials \
+  CEPH_RGW_ENDPOINT=https://s3.ceph.unkin.net \
+  CEPH_RGW_ADMIN_ENDPOINT=https://radosgw.service.consul:443 \
+  CEPH_RGW_ACCESS_KEY='REPLACE-WITH-ACCESS-KEY' \
+  CEPH_RGW_SECRET_KEY='REPLACE-WITH-SECRET-KEY'
+```
+
+The keys under that KV path are copied verbatim into the Secret, so they must be
+named exactly as the table above. VSO refreshes the Secret every few minutes,
+and the deployment's `reloader.stakater.com/auto: "true"` annotation restarts the
+operator when it changes — so rotating the credential is just a new `vault kv
+put`, no manual rollout.
+
+### Fallback: a plain Secret
+
+Outside this cluster (or for a quick `kind` test) you can create the Secret
+directly instead of using Vault:
 
 ```bash
 kubectl -n cephrgw-system create secret generic cephrgw-credentials \
@@ -115,16 +143,8 @@ kubectl -n cephrgw-system create secret generic cephrgw-credentials \
   --from-literal=CEPH_RGW_SECRET_KEY='REPLACE-WITH-SECRET-KEY'
 ```
 
-The deployment carries the `reloader.stakater.com/auto: "true"` annotation, so
+The operator does not care where the Secret comes from, only that those keys
-rotating this Secret triggers an automatic operator restart — no manual rollout
+exist.
-needed.
-
-### Sourcing it from Vault (optional)
-
-If you keep the keys in Vault, sync them with a `VaultStaticSecret` (VSO is
-already running in `vso-system`) that renders into `cephrgw-credentials` with the
-keys above, instead of the plain `kubectl create secret`. The operator does not
-care where the Secret comes from, only that those keys exist.
 
 ---