feat: shared OAuth client behind access key, login/logout commands

[djachenko]

What

Two ways to authorize goodoc:

Path	How	Client
Own Cloud project (default)	first-run wizard	~/.config/goodoc/credentials.json
Author's shared client	goodoc login --key <KEY>	client.py

Plus login / logout commands.

The access key is the client secret

Google's token endpoint rejects this client without a secret — measured, not assumed:

without client_secret -> {"error": "invalid_request", "client_secret is missing."}
with    client_secret -> {"error": "invalid_grant",   "Malformed auth code."}

Since the secret has to reach the user anyway, the key handed out is the secret. The repository ships only CLIENT_ID (public by nature — it appears in every authorization URL) and a sha256 of the key. So the secret never enters git history, and the gate is real rather than decorative: without the key the shared client cannot be used, however carefully the sources are read. The hash exists only to fail fast instead of sending the user through the browser with a bad key.

Already-authorized users are unaffected: token.json carries client id, secret and refresh token, so refreshing never touches client.py.

Shared client limits

Production without verification — no whitelist, but a cap of 100 authorizations for the lifetime of the project, which cannot be reset. Only verification lifts it, and verification requires a domain. Hence the key, and hence "own project" being the default.

Commands became a group

Adding commands turns the app into a Click group, where a variadic argument on the callback swallows the command name — goodoc login gets read as a file path. upload is now a real command, and DefaultCommandGroup inserts it when the first argument is neither a known command nor an option. goodoc file.docx keeps working, so the Automator Quick Action (goodoc "$@") needs no change. This also moves --no-open out of the global options, where it did not belong.

Checks

44 passed, ruff and mypy clean.