[ENHANCEMENT] Add PostgreSQL configuration directly to CoderControlPlane

### Problem
I noticed that connecting a `CoderControlPlane` to `PostgreSQL` is manual. Create a secret with a `postgres://...` URL and set CODER_PG_CONNECTION_URL via `spec.extraEnv`.

The [CloudNativePG example](https://github.com/coder/coder-k8s/tree/main/examples/cloudnativepg) shows one working pattern, but the operator does not own or validate database setup.

It would be nice to have some improvements for this.

### Proposal
Add a clear `spec.database` field on `CoderControlPlane` (name can change) so users declare Postgres connection details in one place.

#### It should support at least:
1. External PostgreSQL - reference a Secret that holds the connection URL (same as Helm: `CODER_PG_CONNECTION_URL` from `postgres://...`).
2. Optional managed PostgreSQL (follow-up or behind a flag) - operator helps wire a Postgres instance the project already documents (e.g. CloudNativePG)

#### The controller should:
1. Set 1CODER_PG_CONNECTION_URL1 on the Coder deployment from the spec (no manual extraEnv).
2. Surface database status (e.g. configured, Secret missing, not ready to start Coder).
3. Surface clear errors when database config is missing or invalid.

### Why this helps
- One manifest describes the control plane and how it connects to Postgres.
- Matches how [Coder Helm installs](https://coder.com/docs/install/kubernetes) already work (Secret + env var).
- Fewer copy-paste steps from examples.
- Clear status when Postgres is not ready yet.

Example:
```
apiVersion: coder.com/v1alpha1
kind: CoderControlPlane
metadata:
name: coder
spec:
image: ghcr.io/coder/coder:latest
database:
connectionSecretRef:
name: coder-db-url
key: url
```

CC: @ibetitsmike @ThomasK33

Interested to know your thoughts! I am willing to make a PR contribution for this as well :)

Start with examples/cloudnativepg and the CoderControlPlane spec/extraEnv configuration described in the issue, then compare the referenced Coder Helm Kubernetes install pattern. Define the external Secret flow first; specify how configured, missing, invalid, and not-ready database states are represented, and leave managed PostgreSQL as a follow-up or flagged scope.

Written by the indexing model from the issue text.