Index the refresh-token lookup, split health checks, add mobile timeouts and validation bounds

[rghvgrv]

Third batch from the review. Branched from current main (c7ad8bc), so #129, #131 and #132 are all included — no conflicts.

Closes #133
Closes #134
Closes #135
Closes #136

#137 (FX batching) and #138 (optimistic concurrency) are deliberately not here — they're design calls, left open.

#133 — unique index on refresh_tokens.token_hash

The table indexed only user_id, but token_hash is what RefreshAsync and LogoutAsync filter on. With 15-minute access tokens and rotation on every use, an active client ran a sequential scan of the fastest-growing table in the schema roughly every 15 minutes.

Unique, not just indexed — the value is a SHA-256 of 32 random bytes, and SingleOrDefaultAsync already depends on uniqueness (two matching rows would throw, not pick one). New migration AddRefreshTokenHashUniqueIndex.

⚠️ Creating a unique index on an existing table fails if duplicates are present. That would need a SHA-256 collision or a duplicated insert, neither of which any code path produces — and if it did, #120's ordering means the migration job fails and the deploy never fires, so schema and running release stay consistent.

#134 — health checks: liveness split from readiness

render.yaml pointed healthCheckPath at /health, which probes Postgres, and Render polls that path continuously for the service's whole life. DEPLOYMENT.md §5 already explains why that's expensive — Neon bills compute and scales to zero, so a database-touching check held awake round the clock burns the allowance — and routes the cron ping to / for exactly that reason. The platform was doing it anyway, more often.

Path	Probes DB	Purpose
/health/live	no	Render's healthCheckPath; anything polling on a schedule
/health/ready	yes	deploy verification, manual checks
/health	yes	unchanged alias for /health/ready

/health is preserved as you asked, so the curl lines in both docs and any existing monitor keep working.

The test that matters: against an unreachable database, /health/live still answers Healthy while /health/ready returns 503. It runs the app in Production, because Program.cs migrates on startup under Development and can't boot against the state the test needs.

#135 — mobile HTTP timeouts

No Refit client set HttpClient.Timeout, so all six plus the refresh client used the 100-second default. This compounded #130: a refused connection fails instantly, but a swallowed one — dead adb tunnel, sleeping instance — hung the full 100s before the offline message.

30s for normal requests (clears a genuine 40–60s cold start), 15s for the refresh client since its wait stacks on top of the request that triggered it. One ConfigureApiClient method now applies base address and timeout to every client, so a client added later can't ship without the timeout — which is how all six ended up on the default.

#136 — validation bounds

CostAmount had GreaterThan(0) and nothing else against a numeric(12,2) column, so anything ≥ 10^10 passed validation and blew up in Postgres as a 500 instead of a 400. Now bounded.

AlertDaysAdvance capped at 365. Nothing overflows server-side, but RenewalNotificationPlanner does NextBillingDate.AddDays(-AlertDaysAdvance), which throws near int.MaxValue; the scheduler catches it, so the app silently scheduled no reminders at all — the feature vanishing rather than failing visibly. Same ceiling on UpdateUserProfileRequestValidator, since that value becomes a subscription's lead time when one is created without an explicit one.

Testing

Suite	Result
SubVora.Api.Tests	123 passed
SubVora.Infrastructure.Tests	99 passed
SubVora.Application.Tests	34 passed
SubVora.Mobile.Tests	160 passed

416 total, 0 failures — run in full against real Postgres via Testcontainers, and re-run after a commit-boundary rewrite to confirm content was unchanged.

New coverage: three health endpoints plus the liveness/readiness distinction under a dead database; the unique index asserted against the migrated schema via pg_index; cost and alert-day bounds at and past the limits; timeout invariants.

After merge

Nothing required — render.yaml is a Blueprint, so healthCheckPath syncs on the next deploy. Worth confirming in the Render dashboard that the health check moved to /health/live, since a manually-set value there can shadow the blueprint.