audit logging and multi-user hardening #14

Fine for a single operator today, but a multi-user instance needs visibility and hardening.

Audit logging — the audit_log table has existed since the first migration and nothing writes to it. Populate it for the security-relevant actions the original plan named, and more: key add/remove (SSH and PGP), email verification changes, access grants/revokes, org membership and role changes, repo transfers/renames/deletes, force-pushes to protected branches, token mint/revoke, admin commands, failed auth bursts. Add gitbayd admin audit (and an admin-only control command) to query it. Include actor, target, timestamp, and source (ssh key fingerprint / API token name).

Hardening — enforce the reserved limits: ssh_auth_rate (per-IP auth throttling) and max_pack_bytes / per-repo quotas; add admin user disable for suspending accounts without deleting them; list and revoke a user's web sessions and tokens administratively; optional expiry warnings for keys.

Events (events table) are the product feed; the audit log is the security feed — separate audiences, both should exist.