Dual-read client-side localStorage keys during the rebrand cutover

[JSONbored]

Problem: Six browser localStorage key literals in apps/gittensory-ui still carry the old brand name and are not covered by any of the 16 known rebrand sub-issues. Renaming them outright, with no migration path, silently resets every returning visitor's saved state — most notably gittensory.session_token, which would force every logged-in visitor to re-authenticate — and also loses saved run views, dismissed-onboarding flags, and notification opt-in state.

Area: Frontend / Client-side storage

Proposal: Apply the same dual-read pattern issue #4773 already uses for the self-host config filename: read the new key first, fall back to the old key once if the new key is absent, and write forward to the new key from then on. Apply this to all six keys:

• apps/gittensory-ui/src/routes/app.workbench.tsx line 33 — 'gittensory.workbench.tab'
• apps/gittensory-ui/src/routes/app.runs.tsx line 505 — 'gittensory.runs.views'
• apps/gittensory-ui/src/routes/app.index.tsx line 437 — 'gittensory.onboarding'
• apps/gittensory-ui/src/components/site/notification-readiness-card.tsx line 32 — 'gittensory_notification_opt_in'
• apps/gittensory-ui/src/components/site/api/try-it.tsx line 19 — STORAGE_KEY = 'gittensory.session_token'
• apps/gittensory-ui/src/components/site/app-panels/onboarding-preview-card.tsx line 20 — DISMISS_KEY = 'gittensory_maintainer_onboarding_preview_dismissed'

Deliverables:

• All six keys above migrated to their renamed equivalents using a read-new-fall-back-to-old-migrate-forward pattern.
• Confirmation that no returning visitor is forced to re-authenticate as a side effect of the rename.
• Confirmation that saved run views, onboarding dismissal state, and notification opt-in state survive the cutover.

Acceptance criteria:

• Every returning visitor's existing state (session token, run views, onboarding dismissal, notification opt-in) carries over across the rebrand deploy with no unexpected reset or forced re-login.
• Each old key is read as a fallback exactly once, migrated to its new key on next write, and the old key is no longer relied upon afterward.

Test scenarios:

• Load the app with only the old-format keys present in localStorage and confirm values migrate to the new keys and prior behavior (e.g., staying logged in, previously dismissed onboarding staying dismissed) is preserved.
• Load the app with both old and new keys present and confirm the new key takes precedence.
• Load the app with neither key present and confirm defaults apply exactly as before.

Resources:

• apps/gittensory-ui/src/routes/app.workbench.tsx line 33
• apps/gittensory-ui/src/routes/app.runs.tsx line 505
• apps/gittensory-ui/src/routes/app.index.tsx line 437
• apps/gittensory-ui/src/components/site/notification-readiness-card.tsx line 32
• apps/gittensory-ui/src/components/site/api/try-it.tsx line 19
• apps/gittensory-ui/src/components/site/app-panels/onboarding-preview-card.tsx line 20
• Issue Self-host config filename migration #4773 (the self-host config filename dual-read precedent this should mirror)

Boundaries:

• Leave every reference to the separate gittensor network's own domain/name untouched.
• Limit this work to the six keys listed above; do not sweep for or rename any other localStorage/sessionStorage keys as part of this issue.

---

Part of #4761.

[linear-code]

JSO-3797