fix(pairing): make the listed pending request approvable

[OutThisLife]

Approving a pending pairing request from an admin surface could not work. list_pending returns the first 8 hex of the code's salted SHA-256 as a field named code — deliberately, so reading the store never reveals the real code — and the dashboard posted that value straight back to /api/pairing/approve, which hashes its input and compares. It never matched. Each click also counted toward the brute-force lockout, so five of them locked the platform for an hour and rejected the correct code at the CLI too.

Verified against the store on main before touching anything:

real code:      MCZNHUZY
list_pending(): [{'code': '07e7d183', 'user_id': '12345', ...}]
approve_code('telegram', '07e7d183') -> None      # what the dashboard sends
approve_code('telegram', 'MCZNHUZY') -> {'user_id': '12345', ...}

[pairing] Platform telegram locked out for 3600s after 5 failed attempts
approve_code('telegram', 'MCZNHUZY') -> None      # correct code, now refused

The code hashing landed in 2e509422e; the dashboard pairing page arrived nine days later in #36704 against the already-hashed shape. The only coverage asserted a 404 on a garbage code — which is also what a correct code returns now, so the suite stayed green.

Pending entries now expose a request_id (the server-side entry key) and PairingStore.approve_request grants on it. That fits how the two surfaces actually authenticate: the DM code proves the channel belongs to the requester, which is why approve_code keeps its proof-of-possession model untouched; a request id is only ever obtained by an admin already authenticated to the store, so it identifies a row rather than proving a secret. Consequently a request-id miss is a stale row, not an attack, and does not touch the lockout counter — otherwise the GUI DoSes the CLI. hermes pairing approve accepts either form and dispatches on shape.

Consolidation

Three open PRs target this defect. Both code-bearing ones are cherry-picked, so authorship survives in git history rather than being reimplemented:

PR	Author	Disposition
#46584	@itsflownium	Cherry-picked as the base — the request-id direction is theirs
#62145	@solyanviktor-star	Cherry-picked; the reset moves into the shared _finish_approval so both grant paths get it
#66761	@lhridley	Intent served structurally — a non-approvable value is no longer printed, so there is nothing to relabel or reject

On top of the salvaged base: dropped the code/code_hash_prefix compat fields (the prefix is what surfaces mistook for a credential; re-exporting the id under the old code key kept the ambiguity alive), gave the duplicated 16-hex sniffing one owner in looks_like_request_id, and fixed the endpoint's chained conditional, which tested that flag against the wrong field and reported a bogus 429 on the request-id path.

Verification

hermes pairing list → copy Request ID → hermes pairing approve telegram <id> → user approved, disappears from pending. Endpoint exercised through TestClient against a temp HERMES_HOME.

Regressions added for the two properties that made this silent: the listing exposes nothing derived from the code and neither grant path accepts the digest prefix; repeated approvals of a stale request id past the lockout threshold leave the code path usable.

60 passed across tests/gateway/test_pairing.py, tests/hermes_cli/test_pairing.py, tests/hermes_cli/test_dashboard_admin_endpoints.py; 111 passed across the gateway pairing/authz/multiplex suites; tsc --noEmit clean in web.

---

Closes #46580
Supersedes #46584
Supersedes #62145
Supersedes #66761

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 37d0766}

ℹ️ Info

Desktop E2E visual evidence · View test artifacts · View job

1 visual diff.

_{inline evidence upload failed.}

Failed to upload diff-665a0833239e-onboarding-overlay-diff.png with gh image (exit code 1): Error uploading /home/runner/work/_temp/e2e-evidence/diff-665a0833239e-onboarding-overlay-diff.png: step 0 (get upload token): uploadToken not found on repo page — do you have write access to NousResearch/hermes-agent? (or, if NousResearch enforces SAML SSO, authorize at https://github.com/orgs/NousResearch/sso)

[alt-glitch]

This was generated by AI during triage.

Related to #46584 and #46580. This uses the same request-id approval direction as #46584 but adds request-id shape dispatch, both CLI paths, and lockout-streak handling; maintainers should choose or consolidate the overlapping patches.