feat(auth): `ct auth token` — a credential-helper interface for the OpenTofu provider

[2000game]

Why

The OpenTofu provider currently declares token as Required: true with no
resolution chain, so every caller has to put a ChurchTools login token into the
environment or a .env file. During the tier-0 cutover that meant writing a
token to local disk, which is the one thing we want to stop doing — the token is
a full-privilege personal credential, and on prod it is an admin one.

ct-cli already solves this: it holds live tokens in the Keychain and resolves
them per --env. The provider should be able to ask ct-cli instead of being
handed a secret, exactly as Terraform's AWS provider resolves credentials
through the AWS CLI's config and SSO cache rather than requiring
AWS_SECRET_ACCESS_KEY.

What

A command whose contract is "print a credential on stdout":

$ ct auth token --env dev
{"host":"https://eqrm-dev.church.tools","token":"..."}

• --env <name> resolves host + token from ct.envs.json as the other commands do.
• JSON on stdout by default; --raw for the bare token.
• Everything else — progress, warnings, the Keychain prompt — on stderr, so
  stdout is safe for command substitution.
• Non-zero exit and nothing on stdout when no token resolves, with a message
  pointing at ct auth login --env <name>.

Prior art for the shape: AWS credential_process, the Kubernetes provider's
exec block, Docker credential helpers, gcloud ADC.

Why a command rather than the provider reading the Keychain

Considered and rejected: teaching the provider to read the Keychain directly in
Go.

1. It reimplements ct-cli's storage format in a second language, which then has
   to track every change to it.
2. macOS Keychain ACLs are per-binary, and the provider binary is rebuilt on
   every CI run and every local go build — so it would prompt for
   authorisation on every single run. Shelling out to ct means the prompt
   belongs to ct, already trusted once.
3. Linux and CI need a different backend regardless.

Notes

• This is the human-credential path only. CI keeps passing the token explicitly
  from GitHub secrets, which is already storage-free.
• Please make sure the token cannot leak into ct-cli's own debug logging.
• Pairs with the provider-side issue in eqrm/terraform-provider-churchtools.

Context: the tier-0 cutover, eqrm/ct-structure#85.

https://claude.ai/code/session_016XVmiQY44pjx1u9Fu4iSDP

[2000game]

Landed in #183, squash-merged as 4ba77e2.

ct auth token emits the ChurchTools session, not the personal login token: the token is permanent, unscopable and an admin credential on prod, while the session expires, is dropped by ct auth logout, and a copy that leaks into a tofu debug log dies within hours. The token never leaves the Keychain.

• credential on stdout and nothing else, so $(ct auth token --raw) is safe; every message on stderr
• failure → empty stdout, non-zero exit, remedy named
• a terminal is refused without --allow-tty
• a cross-process brake on login handshakes per host, since this is meant to be called on every tofu run

Still blocked downstream: the provider's token attribute cannot consume a cookie, so this half is inert until terraform-provider-churchtools learns a cookie+CSRF auth mode. The output shape is now concrete enough to file that against — closing here because the ct-cli side is complete, with the provider work tracked separately.

Note on the throttle, from review: the brake sits in the login handshake, so it covers every ct command, and there is no session cache off macOS. The hourly cap is therefore 120 rather than a number sized for a credential helper alone, so a Linux CI pipeline does not hit it.