fix(identity): ask for credentials on the next sign-in after signing out - #3231

Summary

• After Sign out of an organization server, or Switch account (which signs out first), the next sign-in went through the browser's live session at that server. It finished in one click as the same account, so the user couldn't choose another one.
• The sign-in start URL added prompt=login only when the caller asked for it, and only first run's Use a different account did.
• Now native owns the rule: an explicit sign-out marks that server, and its next sign-in sends prompt=login whatever the caller passes, which asks the sign-in provider to authenticate again. The provider decides what the browser shows; this doesn't end the browser's session there. Only a completed browser sign-in clears the mark. The mark survives a restart, so sign out, quit, then sign in still asks for credentials. Expiry, refusals and close don't set it, so renewing the same account stays one click. No UI change.

Details

• src-tauri/src/federated_identity/mod.rs:
  • State::force_login holds the mark. begin_sign_out sets it, in the same lock as the retirement. Both explicit sign-out paths use it: the plain one and AgentTokens::sign_out.
  • Only a completed browser sign-in clears it (finish_login, in the same lock). A session restored from another Buzz copy takes the mark from the file as it is (reread_signed_out): that session may have been checked before another copy's sign-out, so a restore never erases the mark. A sign-in that a sign-out superseded never installs, so it never clears a newer mark. A failed or canceled sign-in keeps it.
  • sign_in applies it when it admits the attempt (State::asking). The caller's signup hint stays.
  • The mark is kept in <account>.signed-out beside the server's FI records, the same pattern as the .customers list. It is written or removed in the state lock, so the file follows the order of sign-outs and installs. A launch reads it in build. Tests pass no path, as with Customers.
  • A failed write still asks for credentials until the app quits or restores a session. A failed removal asks once more after a restart or restore. Neither changes the session.
• docs/identity.md and docs/buzz-help.md describe the rule.
• Tests:
  • A sign-out marks the server and keeps the caller's sign-up hint. A restarted server still asks, and a completed sign-in clears the mark and the file.
  • A session restored from another copy keeps the mark and the file. A copy that signed out stops asking once another copy's browser sign-in has removed the file.
  • Race: copy B reads the shared session, copy A signs out, then B's verification answers. B installs the session, the mark stays, and a fresh launch's production sign-in URL has prompt=login.
  • The production sign_in start URL has prompt=login after a sign-out and after a restart, and not before a sign-out.
  • Expiry and close leave the next sign-in without prompt=login.

Known limits

• Sign out of Buzz removes the FI records but leaves an existing mark, so a sign-in after it still asks for credentials. It doesn't add a mark (out of scope here).
• Other Buzz copies with the same profile share the file but each holds its own in-memory mark, so a copy that was already running learns about another copy's sign-out at its next launch.
• Not tried against a live sign-in server. The test fixtures check the mark, and the existing login-start test checks that force_login adds prompt=login.

🤖 Generated with Claude Code