fix(quota): make the claim gate atomic, and stop zeroing the storage cache

Two defects in the §9.3 quota path, both invisible to the hermetic suite:

- Audit #4's TOCTOU was real and documented: QuotaCheck and ClaimServer were
  separate statements, so two concurrent claims by one user for two different
  ownerless servers both read count < max_servers and both won. The gate now
  lives inside ClaimServer, in the SAME transaction as the ownership write,
  under pg_advisory_xact_lock(hashtext(user_id)) — the aggregate read, the
  four-dimension re-check (shared with QuotaCheck via one helper so the two
  cannot drift), and the UPDATE are one serialized decision. The loser gets
  ErrQuotaExceeded, which both claim handlers map to the same 403 the
  sequential path gives; the server row is additionally taken FOR UPDATE so
  same-server races still resolve to exactly one winner.

- The server PATCH path called UpdateServerResources(..., 0) for storage even
  though a resources patch cannot change storage. The cached columns are the
  ONLY input to the quota aggregate, so every resource patch silently dropped
  that server's storage contribution from its owner's cap. The handler now
  reads the current spec and passes storage through.

Red-then-green: the new pgint test drives two real concurrent claims against
max_servers=1 (before: both win; now: exactly one win + one gated 403, and the
DB shows one owned row); the hermetic suite pins the 403 mapping and the
storage-preserving cache write.

internal/api/repo.go

@@ -231,7 +231,11 @@ type Repo interface {
 	QuotaCheck(ctx context.Context, userID string, excludeName string, incoming ResourceSpec) (bool, error)
 	// ClaimServer atomically sets owner_id where it is currently NULL and returns
 	// whether a row changed. false means the server was already claimed (spec §9.3:
-	// 0 rows → 409).
+	// 0 rows → 409). The claim runs in one transaction that re-checks the four quota
+	// dimensions under pg_advisory_xact_lock(hashtext(user_id)), so it is the
+	// authoritative gate: a claim that would exceed a cap → ErrQuotaExceeded (403),
+	// and two concurrent claims by one user cannot both pass (audit #4).
+	// QuotaCheck remains the advisory pre-check for the handler's fast-path 403.
 	ClaimServer(ctx context.Context, name, userID string) (bool, error)
 	// UserInAllowlist reports whether the user's linked UUID is on the server
 	// allowlist (spec §9.4).