feat(services): provision a managed Postgres database service (PLO-22)

[ismatBabirli]

What

Create a basic, managed-by-agent PostgreSQL database for an environment from the dashboard — connection info surfaced through the env-config flow, state visible like any other service.

How

A managed database is a template service provisioned from a small, control-plane-owned catalogue (internal/services/templates.go — Postgres today; no template registry table). On CreateDatabaseService the control plane:

1. Fixes the image (postgres:16-alpine) and port (5432) and forces PRIVATE visibility — a database must never get a public Caddy route; only its siblings reach it over the per-environment network at {slug}:5432.
2. Generates the credentials (crypto/rand), and stores them as the service's env vars (POSTGRES_USER / POSTGRES_PASSWORD / POSTGRES_DB) so the agent injects them when it starts the container.
3. Commits the credentials + the service row + the first deployment in one transaction. The env vars are written through a new consumer-defined EnvVarSetter port (satisfied by *envvars.Service, the same shape as the deploy Enqueuer) — so services never imports envvars and env_vars stays owned by its module (modules.md Rule 1/2).
4. Returns the assembled connection URI (postgresql://user:pass@{slug}:5432/db) once.

No agent change is needed — the agent already runs a private image with env injection and sibling DNS.

Changes

• proto: ServiceService.CreateDatabaseService(environment_id, name, template_id, server_id, deploy_now) → {service, deployment_id, connection_uri}.
• services: a databaseTemplate catalogue + CreateDatabase (authorized as a service create, audited as service.create_database); the EnvVarSetter port.
• envvars: SetWithinTx writes a service's env vars inside the caller's tx (no auth of its own — the caller already authorized the create; nothing logged, as these may be credentials).
• dashboard: a "PostgreSQL database" lane in Add a service, and a Connection panel on the service detail that rebuilds host/port/user/db + the full connection string from the stored env vars, each copyable, with a prominent ephemeral-data warning.
• docs: a "Managed database services" section in deployment-engine.md.

Acceptance criteria

• ✅ A Postgres resource can be created and associated with a project/environment — the Add a service "PostgreSQL database" lane provisions a private template service in the chosen environment.
• ✅ Connection information is made available through the env-config flow — credentials are the service's env vars; the connection URI is returned at create time and rebuilt on the service detail's Connection panel.
• ✅ Resource state is visible in the dashboard — a database is a normal service, so its deployment status shows in the service list + detail.

Scope / deferred (noted in deployment-engine.md)

• No persistence yet: the agent mounts no volumes, so a redeploy starts a fresh database. The UI flags the database as ephemeral. Persistent volumes are a later slice (related to PLO-58).
• Password storage: the generated password lives in the service's (plaintext, readable) env vars rather than the sealed-secret path, because secret injection at deploy time isn't wired yet. Moving managed credentials onto that path is a follow-up.

Testing

• make verify green: go build ./..., go test ./..., golangci-lint (0 issues), buf lint, web lint + typecheck. pnpm build (vite) succeeds.
• New internal/services tests: provisions a private postgres template service with generated creds + deploy + audit + connection URI; provisions without deploy_now; rejects an unknown template; denied writes nothing.

[linear-code]

PLO-22

PLO-58