Reconsider auth lifecycle architecture after diagnostics hardening

[jacebenson]

Context

The auth diagnostics work shipped on main in d09f356. It preserves OAuth, Basic Auth, and browser-session/GCK authentication, adds structured per-profile auth status diagnostics, and keeps status probes read-only and secret-free.

During review, the work expanded into broader auth lifecycle hardening. The remaining questions should be reconsidered as a separate design effort instead of continuing to patch the diagnostics slice.

Reconsider

• Define a single profile-identity/instance resolution boundary for every auth lifecycle operation.
• Decide how concurrent OAuth/PKCE flows for multiple profiles sharing an instance should be isolated.
• Make instance-only login, refresh, logout, and remove behavior explicit when multiple profiles share an instance.
• Review bare legacy credential semantics and safe deletion/migration for username-less profiles.
• Review whether auth lifecycle errors should use a single safe redaction boundary.
• Decide whether auth status should probe every profile by default or offer a deliberately bounded strategy.
• Add live-instance coverage for OAuth, Basic Auth, and GCK after the design is settled.

Acceptance criteria

• No auth operation can read, refresh, persist, or delete another profile's credentials.
• OAuth, Basic Auth, and GCK remain distinct with no implicit fallback.
• All read-only diagnostics remain non-mutating and secret-free.
• CLI JSON and human error envelopes remain compatible.
• Shared-instance and concurrent-credential behavior is documented and tested.

This is a follow-up design/review issue, not a request to add another auth mode.