Shared persistent server-side state

Bắt đầu bằng cách đọc src/lib/server/trino/user-clients.ts, src/lib/server/auth.ts, src/lib/server/trino/queries.ts và src/routes/healthz/+server.ts, sau đó kiểm tra values.yaml và các probe của Helm. Quyết định một backing store đáp ứng cả bốn consumer và định nghĩa hành vi của replicaCount. Hoàn thành khi trạng thái dùng chung vẫn tồn tại qua các lần khởi động lại và giữa các replica, /healthz và /readyz có các kiểm tra riêng biệt, và các probe được cập nhật.

Epic: Shared persistent server-side state

All server-side state is held in process-local Maps, so the deployment is capped at one replica and a restart drops everything.
Part of this is already tackled in the ongoing FileBrowser PRs.

[!NOTE]
This text is AI generated against our normal policy because it is migrated from another place, when we tackle this for real it needs to be properly rewritten

Four places:

• Trino connection config — src/lib/server/trino/user-clients.ts:18,
  new Map<string, UserEntry>(). Per-user URL and credentials.
• Sessions and users — src/lib/server/auth.ts. betterAuth() is called without a
  database option, so it uses the built-in memory adapter.
• Query state — src/lib/server/trino/queries.ts:76,79. Progress, rows, status and
  per-tab access times.
• Readiness — src/routes/healthz/+server.ts. Liveness and readiness both point at
  /healthz, which always returns 200.

What this costs

• replicaCount is a plain user-settable chart value (values.yaml:4, documented as
  "Number of replicas") with nothing stopping someone setting it to 2. At two replicas
  users are logged out at random, a query started on one pod is invisible to the other,
  and a saved connection only exists on the pod that received it.
• A restart orphans running queries in Trino, loses completed results, and logs everyone out.
• A readiness probe has nothing meaningful to check, so /readyz would be a placeholder
  until a backing store exists.

Scope

• Pick a backing store and wire all four consumers to it. #41 proposes PostgreSQL for
  better-auth; whatever is chosen should cover all four rather than solving them separately.
• Split /healthz (liveness, trivial) and /readyz (readiness, checks the store), and
  update the Helm probes.
• Decide what replicaCount > 1 does until then: document the constraint, or make the
  chart reject it.

Out of scope

• Persisting completed query results beyond their TTL (STACKABLE_COCKPIT_QUERY_TTL, default 1800s). Separate question.
• S3 credentials in localStorage (#306). Client-side, different problem.