DESIGN.md §4.1/§6: drop namespace from credentialsSecretRef, add key

It's always the operator's own namespace by construction now (§6), never
anything else, so there was nothing for the field to vary -- key varies
instead (fixed 'token' when self-generated, whatever a human chose when
adopted from spec.credentialsSecretRef).

DESIGN.md

@@ -192,7 +192,7 @@ status:
   conditions: [...]                 # Ready, DatabaseReady, Bootstrapped
   observedGeneration: 3
   serviceName: terdut
-  credentialsSecretRef: {name: terdut.platform-oncall-instance-credentials, namespace: terdut-operator-system}  # see §6; lives in the OPERATOR's namespace, not this TerdutServer's
+  credentialsSecretRef: {name: terdut.platform-oncall-instance-credentials, key: token}  # see §6; lives in the OPERATOR's namespace (always, implicitly -- not stored here), not this TerdutServer's. No `namespace` field: unlike an earlier draft, it's never anything other than the operator's own, so there's nothing to record. `key` replaces it, since that *does* vary -- fixed ("token") when the controller generated this Secret itself, whatever the human chose when it was adopted from spec.credentialsSecretRef instead.
 ```
 
 Field-for-field this is the chart's `values.yaml` reshaped as a spec — the
@@ -493,11 +493,11 @@ when nothing ever crosses into a tenant namespace in the first place.
 2. On the self-registration path only (point 1's bring-your-own path
    generates nothing — it adopts the human-provided Secret directly): the
    resulting instance-scoped key is written to a generated Secret in the
-   **operator's own namespace** (e.g. `<serverRef.namespace>.<serverRef.name>-instance-credentials`),
-   referenced back from `TerdutServer.status.credentialsSecretRef: {name,
-   namespace}` (§4.1) — `namespace` is part of the reference now, since it's
-   no longer the same namespace as the `TerdutServer` itself. No
-   `OwnerReference` (those can't cross namespaces); the `TerdutServer`'s
+   **operator's own namespace** (e.g. `<serverRef.namespace>.<serverRef.name>-instance-credentials`,
+   under a fixed data key, `token`), referenced back from
+   `TerdutServer.status.credentialsSecretRef: {name, key}` (§4.1). No
+   `OwnerReference` (those can't cross namespaces, and this Secret doesn't
+   share a namespace with the `TerdutServer` that caused it); the `TerdutServer`'s
    finalizer deletes this Secret directly as part of its own teardown,
    the same way it already has to clean up the server-side resources it
    created (§5's general finalizer rule extends naturally to this Secret).