auth: named-workspace tokens are stored but never used by the API client

[timimsms]

Context

cu auth login -w <name> stores the token in the OS keyring under the named workspace account, but the API client always reads the token for the default account. After a named-workspace login, every API command reports not-authenticated even though the token was saved successfully.

Compounding the confusion, cu auth status honors the default_workspace config value while the API client does not, so cu auth status can report "authenticated" while every other command fails.

Evidence

• internal/auth/auth.go:113-115 — Manager.GetCurrentToken() ignores config and always reads the default keyring account:

// GetCurrentToken gets the token for the current workspace
func (m *Manager) GetCurrentToken() (*Token, error) {
	// TODO: Get current workspace from config
	return m.GetToken(DefaultWorkspace)
}

• cu auth login -w <name> stores the token under the named account, which GetCurrentToken() never reads.
• cu auth status resolves the workspace from config default_workspace, so status and the API client disagree about authentication state.

Suggested fix

Make GetCurrentToken() honor the config default_workspace value (falling back to DefaultWorkspace when unset), so the client reads the same keyring account that auth login/auth status use. Add a test covering login under a named workspace followed by an authenticated client call.