Add compatibility for CLI session token keyring storage

[zedkipp]

Recently the coder CLI added session token storage in the operating system keychain for macOS and Windows. We attempted to make the CLI use the operating system keychain by default, but found that the VS code plugin writes the session token to a directory on the users machine and invokes the coder CLI with the --global-config flag pointing to said directory. This means that coder is unable to use the operating system keyring by default without breaking the plugins expectations. As a result, we had to special case the --global-config flag in coder to not use the keyring. The desire is to have the coder CLI use the keyring by default, unless --use-keyring=false is specified explicitly.

Possible options:

1. Plugin specifies the session token stored on disk to CLI via CODER_SESSION_TOKEN or --token (env var preferred)
2. Plugin reads/writes the session token from the operating system keyring.
3. Plugin specifies --use-keyring=false when invoking coder CLI.

All of the above options have backwards compatibility concerns. Ideally we also remove the --global-config special case from the coder CLI.

I would personally be in favor of option 2) to more closely align with what Coder Desktop does. This would be a user experience improvement (e.g. only need to copy-paste the session token in one application), along with a security improvement (token no longer stored in plain text).

Relates to coder/coder#19403

[EhabY]

I lean towards options (1) and (3), with a preference for (3). The VS Code extension currently assumes it's the authoritative source of session tokens, so passing --use-keyring=false to the CLI aligns with that model.

This would mean users need to log in separately for the extension and CLI, but that's likely unavoidable anyway since the extension supports OAuth login and needs to maintain its own tokens for refreshes and to pass to the CLI when needed.

That said, option (2) could work well with a fallback approach: when the extension detects invalid or missing auth for a given hostname, it could check the system keyring before prompting for OAuth or a session token. This would provide the UX benefits you mentioned (single login across applications) without breaking the extension's current token management model.