Stored tokens are not bound to the server that issued them; whoami never verifies with the server #386

Problem

A stored token records no association with the server that minted it. Under a multi-profile config — or a single profile whose server_url is re-pointed after login — the CLI will attach one server's token to a different server. The server rejects it with an opaque 401, and /auth/refresh cannot heal it either (it validates the existing token's own signature), so the only real remedy is kcap login. Nothing in the CLI says so.

kcap whoami makes this considerably harder to diagnose: it prints only local token-file metadata (username, provider, expiry). "Expires tomorrow" means a clock hasn't passed — not that any server accepts the token. So whoami reports a perfectly valid-looking token while every request is being rejected.

Two related gaps:

• Token lookup ignores the resolved profile. ProfileResolver can select a profile via KCAP_PROFILE, a repo .kcap.json, a git-remote match, or a kcap use binding, but TokenStore always reads the on-disk active_profile. A repo bound to profile X still sends profile Y's token.
• Interactive commands have no 401 recovery. The SessionStart memory hook path retries once with a forced refresh; CreateAuthenticatedClientAsync does not, so a locally-unexpired-but-rejected token is a hard failure there.

Repro (as originally observed)

On a machine with multiple kcap profiles, an authenticated client built for an explicit base URL returned 401 on its first request, while kcap whoami (with and without KCAP_URL) reported a valid, unexpired GitHubApp token for that same server.

Expected

• A token is only ever presented to the server that issued it; a mismatch produces an actionable local message naming both servers instead of a bare 401.
• Token lookup follows the profile the process actually resolved.
• kcap whoami reports whether the server accepts the token, distinguishing rejection from "couldn't ask".

Linear: AI-1504