fix(auth): stop auditing routine device-flow polls as denied, mark access_denied correctly

[kai392]

Summary

pollGitHubDeviceFlow (src/auth/github-oauth.ts) audited every non-success device-token response, categorising RFC 8628's routine polling states as denied and the one genuine user rejection as a generic error — exactly backwards from how outcome: "denied" is used everywhere else in the codebase.

• authorization_pending / slow_down — the expected response on nearly every poll of a login still in progress (~180 rows per successful login at the 5s interval over the 900s window) — now write no audit row at all. They carry no information beyond "keep polling", so they aren't audit-worthy.
• access_denied — the actual "user declined" signal — is now the sole outcome: "denied", matching how the sibling web-OAuth callback in routes.ts treats an OAuth error param.
• Every other terminal code (expired_token, bad_verification_code, incorrect_client_credentials, or anything else GitHub returns) keeps outcome: "error", unchanged.

Audit-categorisation only: the returned { status, message } shape, the token issued, the scopes granted, and every caller of /v1/auth/github/device/poll are all untouched.

Closes #8378

Test plan

• New regression test in test/unit/auth.test.ts asserting all three arms: both routine states produce zero auth.github_device_poll rows while still returning their { status, message }; access_denied produces exactly one row with outcome: "denied"; expired_token still records outcome: "error"
• The existing pollGitHubDeviceFlow coverage passes unmodified — including its bad_verification_code → outcome: "error" assertion and its authorization_pending/slow_down return-value assertions (this change is additive to expectations, it weakens nothing)
• test/unit/auth.test.ts green (37/37); every changed line and both new branch arms are covered — the diff hunk (src/auth/github-oauth.ts lines 86-97) contains none of the file's pre-existing uncovered lines/branches
• npm run typecheck clean
• CI validate

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.58%. Comparing base (d8f706c) to head (acf8259).
⚠️ Report is 40 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8400      +/-   ##
==========================================
- Coverage   92.12%   89.58%   -2.55%     
==========================================
  Files         782       98     -684     
  Lines       78531    22751   -55780     
  Branches    23720     3915   -19805     
==========================================
- Hits        72347    20381   -51966     
+ Misses       5062     2189    -2873     
+ Partials     1122      181     -941     

Flag	Coverage Δ
shard-1	79.06% <100.00%> (+19.12%)	⬆️
shard-2	55.81% <0.00%> (+8.59%)	⬆️
shard-3	66.66% <0.00%> (+13.14%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/auth/github-oauth.ts	96.12% <100.00%> (+0.03%)	⬆️

... and 684 files with indirect coverage changes

[loopover-orb]

Tip

✅ LoopOver review result - approve/merge recommended

_{Review updated: 2026-07-24 11:37:23 UTC}

2 files · 1 AI reviewer · no blockers · readiness 98/100 · CI green · clean

✅ Suggested Action - Approve/Merge

• safe to merge

Review summary
This diff correctly inverts the audit-outcome logic in pollGitHubDeviceFlow: routine RFC 8628 polling states (authorization_pending, slow_down) now skip auditing entirely, access_denied is the sole 'denied' outcome, and all other terminal errors (expired_token, bad_verification_code, etc.) retain 'error' — matching the sibling web-OAuth callback's convention. The change is narrow, correctly scoped to the audit-categorization concern described in the PR, and is backed by a new regression test that exercises all three branches against the real function (not a fabricated payload) plus the untouched pre-existing test still asserting bad_verification_code stays 'error'. The `{status, message}` return shape is unchanged for every branch, so no caller of /v1/auth/github/device/poll is affected.

Nits — 3 non-blocking

• The three stacked prose comments above the diff (src/auth/github-oauth.ts:86-90) are unusually long for a single conditional; consider trimming to one or two sentences per this file's own convention (compare the terser inline comments elsewhere in the file, e.g. the GITHUB_TOKEN_REFRESH_MARGIN_MS comment).
• test/unit/auth.test.ts's new regression test builds its own local auditRows()/pollWith() helpers duplicating patterns already used in the file (e.g. the DB.prepare(...).all() pattern); not worth abstracting for one test, but worth noting if a third caller appears.
• Consider a short code comment or test case documenting that `outcome: "denied"` values are expected to be rare/actionable so future readers querying `audit_events` know a `denied` row for this event_type is a genuine signal worth alerting on, not noise.

Decision drivers

• ✅ Code review — No blockers (1 reviewer)
• ✅ Gate result — Passing (No configured blocker found.)

Context & advisory signals — never blocks the verdict

Signal	Result	Evidence
Linked issue	✅ Linked	#8378
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 107 registered-repo PR(s), 58 merged, 4 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	kai392; Gittensor profile; 107 PR(s), 4 issue(s).
Improvement	✅ Minor	risk: clean · value: minor · LLM: moderate

Linked issue satisfaction

Addressed
The diff exactly implements the requested logic: no audit call for authorization_pending/slow_down, outcome 'denied' only for access_denied, outcome 'error' for all other terminal codes, and the returned {status, message} shape is unchanged; the added test covers all three arms including the regression guard for bad_verification_code/expired_token.

Review context

• Author: kai392
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: not available
• Official Gittensor activity: 107 PR(s), 4 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

🧪 Chat with LoopOver

Ask LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.

• @loopover ask <question> answers contribution-quality Q&A with source citations and freshness.
• @loopover chat <question> answers in natural prose from cached decision-pack facts via local inference (maintainer/collaborator; read-only).
• A plain-language @loopover mention with a real question is routed to the closest matching read-only command automatically — no exact syntax required.

Full command reference: https://loopover.ai/docs/loopover-commands

🧪 Experimental — new and may change.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.

• Re-run LoopOver review

[loopover-orb]

LoopOver approves — the gate is satisfied and CI is green.