feat(auth): add non-interactive gog auth import subcommand

[jcarnegie]

Summary

Adds gog auth import --client <id> --email <email> --refresh-token <token> --services <csv> [--force] for storing a pre-existing OAuth refresh token in the configured keyring without going through the browser-based auth flow.

This is the non-interactive counterpart to gog auth add: the refresh token has already been minted out-of-band (e.g., by an automation runner or pulled from a secret store) and we just need to land it in the keyring so the rest of gogcli can use it.

Behavior

• --client defaults to "default" and namespaces the keyring entry (matches existing config.DefaultClientName semantics).
• --email is required and is normalized (trimmed + lowercased) before storage.
• --refresh-token is required; whitespace-only values are rejected with exit code 2 and a human-readable error.
• --services accepts a comma-separated list; recorded on the token for gog auth list display purposes (does not affect scope grants — this command does not exchange or validate the token).
• --force overwrites an existing entry; without it, importing over an existing client/email entry returns a usage error.
• Honors --dry-run / -n like other mutating auth commands.
• JSON output via --json returns {"imported": true, "client": "...", "email": "..."}.

After import, gog auth list will display the new account.

Files

• internal/cmd/auth_import.go — new AuthImportCmd and Run method.
• internal/cmd/auth.go — register Import under AuthCmd.
• internal/cmd/auth_import_test.go — command-level tests covering: empty refresh-token rejection, empty email rejection, default-client namespacing, custom-client namespacing, existing-entry rejection without --force, --force overwrite, and --dry-run no-op.
• internal/secrets/store_test.go — focused SetToken roundtrip tests asserting Services preservation and overwrite-on-resave behavior.
• CHANGELOG.md — Added entry under 0.17.0 - Unreleased.

Why

Downstream automation (the ClawInstall project) provisions refresh tokens server-side and needs a deterministic, no-prompt way to seed them into a fresh keyring. The existing auth tokens import requires a JSON file in the export format; this command takes the fields directly as flags, which is what the automation actually has on hand.

Linear

Tracks Linear CLA-287.

Test plan

• go test ./internal/cmd/... -run AuthImport
• go test ./internal/secrets/... -run KeyringStoreSetToken
• Manual: gog auth import --email user@example.com --refresh-token "$RT" --services gmail,drive then gog auth list shows the entry.
• Manual: re-running the same import returns a usage error; with --force it overwrites.