feat: user API key for automation (self-certify persona)

[coopernetes]

Summary

Allow users to generate a proxy-native API key as an alternative credential for authenticating pushes through the proxy. Targeted at the self-certify persona — users running agentic/automated pipelines who currently have to embed a GitHub PAT in their remote URL just to satisfy Basic auth.

Motivation

Users with the self-certify permission who run automated or AI-assisted workflows need a clean credential for unattended pushes. The current workaround (PAT in remote URL) works but is not ideal — it ties the proxy credential to an upstream SCM token and makes rotation awkward.

A proxy-native API key keeps the credential scoped to the proxy identity and decouples it from upstream SCM tokens.

Behaviour

• The API key is bound to the user's proxy account — the existing permission check runs as normal after resolution. If the user has self-certify, automation gets self-certify. If they don't, the push is blocked.
• The audit log records pushes authenticated via API key identically to password-authenticated pushes.
• No new policy model or permission scope is needed — this is purely an alternative auth credential.

Implementation sketch

1. Add api_key_hash column to proxy_users (nullable — opt-in)
2. Accept API key in StoreAndForwardReceivePackFactory.extractUserPass as an alternative to password auth — resolve user by key hash, set pushUser and pushToken as normal
3. Profile page: "Generate API key" / "Revoke API key" button — show the key once on generation (never again)
4. JdbcUserStore: setApiKey(username, hash) / revokeApiKey(username) methods

Out of scope

• Key scoping or expiry (can be added later)
• Multiple keys per user

Future

Key expiry, read/write scopes, and OAuth2 client_credentials grant support are tracked in #57.