fix(agentgit): register the member's SSH key on every BBS login, not just at signup

[ralyodio]

What

When a member joins the BBS, their SSH key is supposed to be registered on their
git.profullstack.com account — "your BBS SSH key is your git key", as the pod
banner says. It only ever happened once, at first provisioning.

provisionGit bailed out before reaching EnsureKey:

created, password, err := a.forgejo.EnsureUser(u.Name, u.Email)
if !created { return }   // <- every later login stops here
... a.forgejo.EnsureKey(...)  // unreachable after the first time

So a member who deleted their key on AgentGit never got it back, and members who
joined before AgentGit captured keys were never backfilled — even though the
login path at main.go:519 calls provisionGit on every visit specifically to
do that, and its comment says so. The web verify path's comment ("key is added
on next BBS login", main.go:1217) described behaviour that could not happen.

Change

Key registration now runs on every provisionGit call that carries a session
key. EnsureKey was already idempotent — it GETs the account's keys and
compares key material ignoring the trailing comment — so re-running it costs one
GET when nothing changed, and it re-adds a removed key, picks up a rotated one,
and backfills old accounts. The welcome email stays gated on created, since
the one-time password is empty for an account that already existed.

Two things that would have made the every-login path unreliable:

• Key title was the constant "agentbbs". Forgejo 422s a duplicate title,
  so a member who rotated their BBS key would have had the new key silently
  dropped. The title now carries a short fingerprint (agentbbs <fp>), so
  distinct keys coexist and the same key stays stable across logins.
• EnsureKey mapped every 422 to "already exists" and returned nil. That
  hid genuine rejections forever, which matters much more now the call is on the
  hot path. Only "has been used" bodies are swallowed; anything else surfaces
  with Forgejo's own reason so it reaches the logs.

Tests

• TestProvisionGitRegistersKeyForExistingAccount — the regression guard: with
  an account that already exists, the key must still be POSTed. Fails against
  the old early-return.
• TestGitKeyTitleIsPerKey — distinct keys get distinct titles, the same key is
  stable, unparseable input degrades to "agentbbs".
• TestEnsureKeyTreatsAlreadyUsed422AsBenign / TestEnsureKeySurfacesRejecting422
  — the two sides of the 422 split.

gofmt, go vet and the full go test ./... suite are clean.

Not covered here

Pushing over SSH to AgentGit is still broken for an unrelated reason: Forgejo
advertises ssh://git@git.profullstack.com:2222/…, but 2222 is not reachable —
it times out, while 587 on the same host answers refused, so the live ufw
ruleset has no ACCEPT for it despite setup.sh carrying
ufw allow "${FORGEJO_SSH_PORT}/tcp" since f210b42. Port 22 there is agentbbs
itself, so the pod banner's git push → git@git.profullstack.com fails with
fatal: protocol error: bad line length character: Requ (the BBS's "Requires an
active PTY" parsed as git protocol). Needs a look on the box; HTTPS remotes work
today.

🤖 Generated with Claude Code

[github-actions]

ThreatCrush Security Scan

10 finding(s)

HIGH/CRITICAL: 7 | LOW: 3

Severity	Rule	Location
HIGH	secret-generic-credential	deploy/ergo/ircd.yaml:162
HIGH	secret-generic-credential	deploy/ergo/ircd.yaml:221
HIGH	secret-generic-credential	deploy/ergo/ircd.yaml:638
HIGH	secret-generic-credential	deploy/ergo/ircd.yaml:787
HIGH	secret-database-url	deploy/ergo/ircd.yaml:893
HIGH	secret-generic-credential	deploy/ergo/ircd.yaml:1025
HIGH	secret-generic-credential	deploy/ergo/ircd.yaml:1033
LOW	secret-generic-credential	deploy/ergo/ircd.yaml:772
LOW	tls-verification-disabled	internal/mail/mail.go:109
LOW	secret-generic-credential	internal/mailu/mailu_test.go:44

Snippets are redacted; ThreatCrush never prints matched credential material.