Ask before a pasted secret replaces the signed-in account

[joepio]

Before: signed in to atomic.place as joep@ontola.io, pasting an agent secret for another agent (an older atomicdata.dev agent, or a local node's) signed that account out right away, including out of atomic.place, since the portal and the app share the session. Only afterwards did a toast say "Signed out of your account here — that secret belongs to a different one", without saying which account or which agent.

After: the sign-in stops on "This secret is for a different account". It names the signed-in account, shows its agent next to the secret's agent, and offers "Stay signed in as joep@ontola.io" (the default) or "Use this secret and sign out". The session is only ended after the second choice, and the toast then names the account that was signed out.

How: secretAccountConflict() in recovery.ts compares the account backup's agent with the secret's agent through sameAgent, so did:ad: and atomic: spellings still count as one agent. handleSignInWithSecret in GettingStartedFlow.tsx runs that check before it stores or activates the agent, shows the new secret-conflict step when they differ, and calls releaseConflictingPortalSession only after the user confirms. There are unit tests for the helper and component tests for both choices and for the matching-agent path. The two conflict tests fail on develop. The .po catalogs were extracted with wuchale without --clean.

---

Generated by Claude Code

[joepio]

Run 4749 on d24311a (this PR with develop 58408ac merged in) is red on one e2e test, and it failed all three attempts: canvas-live-update.spec.ts:71 "a stroke drawn in one session appears live in another session viewing the same canvas", each time on the 60 s test timeout. Everything else passed (75 passed, 3 skipped).

This test looks like it belongs to this PR rather than develop:

• Its second session signs in by pasting the dev agent's secret on /app/welcome (openNewSubjectWindow(browser, subject, secret) → signIn). That goes through handleSignInWithSecret, the path this PR changes.
• The same test passed on develop run 4747 (cb085dc, which already carries fix(lib): stop a Loro panic erroring on a timer for the life of the tab #1860), and on fix(lib): say what actually blocks disconnecting a workspace #1790's run 4745.
• It also passed on this PR's own earlier run 4728. So the likely trigger is this PR's secret check meeting something develop added since then, Offer to bring a browser workspace into the account on an identity conflict #1865's identity reconcile being the closest candidate. That part is inferred, not traced.

Handed to the thread that owns this PR. I'm not re-running, because three failed attempts in one run is not a flake.

---

Generated by Claude Code

[joepio]

The red canvas-live-update.spec.ts:71 in run 4749 doesn't come from this PR. It fails the same way on develop:

• Develop run 4748 on 58408ac, the develop commit merged into d24311a: the same test times out after 60 s on all 3 attempts, stalling on the final repaint poll at line 113. The passing run 4747 was on cb085dc, which is older than 58408ac. Offer to bring a browser workspace into the account on an identity conflict #1865 was already in 4747, so it isn't the trigger.
• This PR's check isn't reached in e2e: findSecretConflict returns null without a network call, because hasManagedApi() is false in the e2e build, which only sets VITE_E2E. So the sign-in path matches develop's.
• Locally on d24311a, the spec passed, including 4 of 4 with --repeat-each 4 --workers 4.
• Load is a suspect: 4748 and 4749 ran at the same time on Mancave and Mancave-2, so load is plausible. That's inferred, not proven.

No fix exists for it yet. Develop run 4750 will show whether it's load or a regression on develop.

---

Generated by Claude Code