fix: read account state from private REST API after OpenRouter removed Server Actions

[erikchi]

Symptom

All stations failing again, consecutive_failure_count: 350:

{"reason":"failed_to_fetch_activity",
 "error_detail":"no activity hash found, available: map[] (pages_ok=2 pages_signed_out=0 chunks_seen=3425 chunks_fetched=85)"}

The diagnostics added in #4 did the triage: pages_ok=2 (cookies alive), chunks_seen=3425 (bundle discovery healthy after the last fix). So the break was downstream of both — not cookies, not the bundle path.

Root cause

OpenRouter migrated their private frontend off Next.js Server Actions onto REST + React Query. getCurrentUserSA no longer exists, so there is no action hash left to find.

Ground truth from the authenticated /activity page:

• All 79 referenced chunks fetch 200 — nothing is missing or 404ing
• The only server actions left in the bundle are errSA, refreshSA, sealSignupCfMetadataSA
• getCurrentUserSA is replaced by React Query hooks — useCurrentUser, currentUserOptions, currentUserKeys — whose queryFn targets:

GET /api/frontend/v1/private/users/current  →  {"data": { email, enable_training, enforce_zdr, ... }}

That single endpoint carries the email and every user-scope required toggle. The workspace-scope toggle still comes from the SSR settings page, which is unaffected.

Fix

FetchActivityData now calls the REST endpoint first, keeping the legacy server-action paths as fallbacks so an upstream revert costs us nothing. Response unwrapping is a pure parseCurrentUserResponse so the contract is unit-testable without a live session.

This also removes the verifier's dependence on scraping the minified bundle for user data — the layer that broke twice this month: first when the bundle moved to /_next/static/immutable/chunks/ (#4), now when the action it hosted was deleted. A REST contract is the more stable surface.

Verification

End-to-end against a live account:

Action hashes: map[]              ← dead machinery, untouched
Activity data fetched successfully!
Result: ok
  enable_training ... OK (false) [user]      (7/7 required toggles OK)

The empty hash map is the point: the new path succeeds without it.

Tests cover the success envelope, the real 401 No user or org id found in auth cookie body, and rejection of empty/HTML responses — the last one matters because a signed-out page must never be mistaken for a compliant account. go build ./... and go test ./... green.

⚠️ Not fixed here — new registrations still broken

CreateProvisioningKey / DeleteProvisioningKey still use the removed provisioning_keys_create / provisioning_keys_delete actions, so registration and unregister remain broken; already-registered stations verify fine. Replacement endpoint is /api/frontend/v1/private/management-keys. Left out because exercising it creates a real management key on a live account — wanted a decision before doing that.

🤖 Generated with Claude Code