credits/aisandbox: the shared retry helper's SAPISID remediation still misleads on every non-credits route #803

Split out of #795 so that fix stays scoped to the surface it was verified on.

What is left

#802 removed the class-default AisandboxAuthError remediation from the credits path. Three raise sites in api/client.py still carry it, and they serve every other aisandbox route — scene, character, project, data:

src/gflow_cli/api/client.py:1545   AisandboxAuthError  (non-JSON /auth/session response)
src/gflow_cli/api/client.py:1554   AisandboxAuthError  ("no access_token in /fx/api/auth/session (session expired?)")
src/gflow_cli/api/client.py:1633   AisandboxAuthError  ("aisandbox-pa returned 401 after token refresh")

All three inherit errors.py's default:

SAPISID cookie missing, expired, or unreadable. Re-run gflow auth login --profile <name> and retry.

:1554 is the same tokenless-migrated condition api/credits.py just got a custom hint for, reached through the browser instead of httpx. On an account Google has migrated to flow.google.com, that advice cannot work, and on a profile with no browser-strategy marker a failed first login rolls the marker back — the #791 spiral.

Why it was not fixed in #802

Two reasons, both worth stating rather than assuming away:

1. _run_with_aisandbox_retry is route-blind by design. It is shared by _post_json, _patch_json and _get_json, so it cannot carry a per-route remediation. The hint belongs at the raise sites that know their route, or the helper needs the route threaded into a lookup — a design question, not a string edit.
2. The class default is not simply wrong. For a genuinely expired labs session, gflow auth login IS the fix. Replacing it wholesale would trade one misleading message for another. What is needed is a way to distinguish the cohorts at those sites, which nobody has measured yet.

What would settle it

A migrated account driving a non-credits aisandbox route (gflow scene, gflow character) to the point where one of these three fires, with the log. Per [[maintainer-account-lost-the-bearer-2026-09-11]] the maintainer account is in that cohort now, so this is likely reproducible at $0 — but it has not been run, and this issue is filed rather than guessed.

Refs #795, #791