docs(provisioner): retire stale "-1 = unlimited (team/growth)" comment examples (P4-1)

[mastermanas805]

What & why (Bug-hunt iter4 finding P4-1)

The strict-80 margin redesign (merged to common+api master 2026-06-05) retired the -1 "no limit" sentinel from every tier's resource limits. postgres_connections and redis_memory_mb are now finite for every tier (team=100 conns / 1536 MB, growth=20 conns / 1024 MB, pro=20 conns / 512 MB). The provisioner's code is correct (it applies whatever the plans registry passes), but several comments still gave the now-misleading example -1 = unlimited (team/growth) / team: unlimited (-1).

This corrects every stale tier-attributed example to be accurate:

• The -1 / <= 0 sentinel branches stay — they remain the wire contract, and the pool-prewarm path (internal/pool/manager.go) still passes -1 deliberately, so the branch is live.
• Pure sentinel-mechanism docs that name no current tier were kept (accurate) with a brief post-strict-80 note added to the public entry-point docs (Backend.Provision, Regrader.Regrade, LocalBackend.Provision/Regrade).
• The two dedicated-pod sizing literals (redis/k8s.go maxmemoryMB: -1, postgres/k8s.go connLimit: -1) are byte-identical — only their surrounding comments changed, now noting the runtime cap is reconciled to the finite registry value via Regrade.

No production behavior change.

Also: fixes a pre-existing FAILING test

make gate was already red on origin/master: TestRegradeResource_Redis_ProTier_AppliesCap/team asserted maxmemory=0 (old team redis_memory_mb=-1) while the registry now returns 1536 — a test expectation strict-80's common bump left behind. Reworked to derive expected values from the live plans registry (rule 18) so the same drift can never recur silently. The production code already applied the registry value; only the stale test expectation changed.

Coverage block

Symptom:       comment example "-1 = unlimited (team/growth)" / "team: unlimited (-1)" + test asserting team maxmemory want 0
Enumeration:   rg -n 'unlimited|connLimit.*-1|-1.*unlimited' provisioner/internal/
Sites found:   stale tier-attributed examples across 6 source files (server.go, redis/k8s.go, redis/backend.go, postgres/backend.go, postgres/local.go, postgres/k8s.go) + 2 test files
Sites touched: all stale tier attributions corrected; accurate pure-sentinel mechanism docs retained, with post-strict-80 note on entry-point docs
Coverage test: TestRegradeResource_Redis_ProTier_AppliesCap is now registry-driven (rule 18) — fails automatically if a future registry change drifts it
Live verified: doc-only / test-only change — full make gate (build + vet + go test ./... -short) GREEN locally; golangci-lint 0 issues

Latent issue surfaced (NOT fixed here — out of scope)

sizingForTier in both dedicated-pod backends still hardcodes -1 (redis/k8s.go maxmemoryMB, postgres/k8s.go connLimit) for team. At provision time the k8s postgres backend uses sz.connLimit (Provision ignores its registry-passed connLimit param — see the existing doc at K8sBackend.Provision), so a team dedicated postgres role is briefly created uncapped until the reconciler's first Regrade applies the finite registry value (100). The redis pod similarly starts with no --maxmemory flag and gets capped to 1536 on the next Regrade. This is functionally reconciled but not provision-time-correct; flagged in the comments and worth a follow-up to pass the registry value at provision time. Left out of this comment-only PR.

🤖 Generated with Claude Code