orb(identity): miner detection matches on the renameable GitHub login while a stable githubId is available and discarded

[JSONbored]

src/gittensor/api.ts ~185:

const miner = miners.find((c) => c.githubUsername?.toLowerCase() === normalizedLogin);

The upstream response carries a stable githubId — used two lines later to fetch detail, and to build the public miner link — but the match is on the renameable, reclaimable username. ORB never stores a numeric author id anywhere: GitHubPullRequestPayload.user is typed as {login, type} only (src/types.ts ~405), so there is nothing to cross-check against even if you wanted to.

confirmed_miner is a genuinely elevated role. packages/loopover-engine/src/settings/command-authorization.ts grants it the default command set and review (self-retrigger), and its own comment states the clamp "drops only the spoofable plain pr_author role; confirmed_miner survives" — i.e. it is explicitly trusted as non-spoofable. It also selects the miner open-PR cap (src/queue/processors.ts ~2709, ~5609) and the unlinked-issue-guardrail velocity exception (src/review/unlinked-issue-guardrail.ts ~274).

Exploit prerequisites: a registered miner renames or deletes their GitHub account while the upstream /miners list still carries the old username; an attacker claims the freed login (GitHub frees it immediately) and inherits the elevated role. Exploitability depends on upstream refresh cadence, so the exploit is SUSPECTED even though the defect is confirmed.

Fix

Capture pull_request.user.id from the webhook and match miner detection on githubId, treating the username as a display field only.

[linear-code]

JSO-6281