Auth: document multi-account switching as auth-model-blocked

[Adron]

Finding

Multi-account support (GET /api/auth/accounts, POST /api/auth/switch, POST /api/auth/remove-account) declares cookieAuth in the live spec, and the live probe confirms it:

GET /api/auth/accounts -> 401 {"error":"Unauthorized","code":"unauthorized"}

A bearer sync-token client cannot obtain a cookie session, so this is structurally unavailable — the same category as Stripe checkout/portal.

However

A native client could offer its own multi-account support without these endpoints: hold several sync-tokens locally and switch which one InterlinedApiClient uses. That is a client-side feature, not an API one — worth a decision rather than an assumption.

Acceptance criteria

• CLAUDE.md records the cookie-only status of these three endpoints with the 2026-09-15 probe result.
• A decision recorded: either implement client-side multi-token switching (which would mean extending CredentialStore from one session.dat to a keyed store, and coordinating with InterlinedList.Sync, which reads that exact file) or declare multi-account out of scope.
• No UI ships that calls these endpoints with a bearer token.

[Adron]

Part 1 (documentation) is done; part 2 needs your decision — leaving this open

Confirmed: all three endpoints are cookie-only

Re-probed live 2026-09-16 with the .env test account's bearer sync-token:

GET  /api/auth/accounts       -> 401 {"error":"Unauthorized","code":"unauthorized"}
POST /api/auth/switch         -> 401 {"error":"Unauthorized","code":"unauthorized"}
POST /api/auth/remove-account -> 401 {"error":"Unauthorized","code":"unauthorized"}

This matches the spec's declared cookieAuth, and it is consistent rather than drifting (unlike /api/user/engagement and /api/user/dashboard-layout, which flipped — see #124). A bearer-token client structurally cannot obtain a cookie session, so the server-side multi-account API is unavailable to this app, permanently, by design.

✅ Acceptance criterion 1 is already satisfied — #129 records all three in CLAUDE.md's confirmed cookie-only set with the probe date.

✅ Acceptance criterion 3 is satisfied trivially — no UI calls these, and none will.

Acceptance criterion 2 is a real architecture decision, and it isn't mine to make

The issue offers two paths. Here's what each actually costs, now that I've looked at the code.

Option A — declare multi-account out of scope. Zero work. Close this issue.

Option B — client-side multi-token switching. The API isn't needed for this: the app could hold several sync-tokens locally and switch which one InterlinedApiClient uses. But it is not a contained change, because of one detail:

Services/CredentialStore.cs stores exactly one token at a fixed path:

private static readonly string TokenPath = Path.Combine(
    ..., "InterlinedList", "session.dat");

and the sync tray utility reads that same file as a contract:

• InterlinedList.Sync/SyncPaths.cs → SessionFile = …/InterlinedList/session.dat
• InterlinedList.Sync/SessionTokenFile.cs — "Reads/writes the SAME DPAPI-encrypted session.dat the main app uses"
• InterlinedList.Sync/AuthClient.cs — "so signing in here also signs in the main app, and vice versa"

That shared file is the whole of the "unified auth" design in CLAUDE.md. So Option B means:

1. Changing session.dat from one token to a keyed store — a format migration for an installed app, needing a read-old-write-new path so existing users aren't silently signed out.
2. Deciding what the tray utility does when the main app has three accounts. It syncs one document tree to one folder. Does it follow the active account (so switching accounts silently re-points a synced Obsidian folder — data-loss-adjacent), pin to one account, or sync per-account folders? This is the substantive question, and it's a product decision about the sync utility, not a coding one.
3. Reconciling with Auth: real logout (POST /api/auth/logout) #114 (real logout): logging out of one account must not invalidate the others.

My recommendation: Option A for now, and revisit only if users ask. Not because it's hard, but because the sync-utility interaction in (2) has a plausible data-loss shape, and the payoff — a convenience the web gets for free from cookies — is low for a desktop client where a second account can be reached in a browser.

What I need from you

Pick a path, or tell me to go with the recommendation:

• A: I close this as out of scope and add a one-line note to CLAUDE.md.
• B: I'd want an answer on (2) first — what should the sync utility do when several accounts exist? That answer determines the design, so I'd rather not guess it.

Everything else on this issue is complete.