fix(auth): the browser-JWT branch now carries username, email and role

[lilyshen0722]

middleware/auth.ts dispatches on the token prefix and leaves two different shapes on req.user:

branch	assigns
cm_ API token (:51)	{ id, username, email, role }
browser JWT (:81)	{ id }

Nothing errors. Consumers just read undefined for every browser session.

Two live consequences, both confirmed at 799e0d7d

• github.ts:146 — if (req.user?.role !== 'admin') return res.status(403). A genuine admin in a browser session is refused 403 Admin only; the same admin holding an API token gets through. Fails closed, loudly.
• registry publish/install — publisher.name persists as undefined. Fails open, silently. This is fix(registry): publisher.name is undefined for every browser-session publish #1211's defect.

Why one fix rather than two

Three call sites had already grown a private DB re-read to work around this, each with its own comment rediscovering the same cause:

• podController.isGlobalAdminRequest (:43)
• agentProfile.canEditAgentAvatar (:250) — "JWT auth populates req.user = { id } WITHOUT role (middleware/auth.ts:81)"
• marketplace-api.resolveUsername (:11) — which fix(registry): publisher.name is undefined for every browser-session publish #1211 copies into registry/helpers.ts under a comment saying it was moved

github.ts is the fourth site, and the one that never got its copy. Fixing it locally would make four.

The JWT branch already runs one indexed User.findById(id) per request for ban enforcement (#636). Widening that projection from banned to banned username email role makes the branches shape-identical at zero extra round-trips, so no consumer has to know which token type it was called with. The three existing local re-reads stay correct and become redundant fast-paths — removing them is separate work, deliberately not in this PR.

On the test

It drives the real middleware over a real JWT. The suites covering the affected routes cannot see this defect: their fake auth middleware injects req.user = { _id, role } directly — the API-token shape — so #809's /status tests pass today against the broken predicate.

The User mock honours the projection string, and that is load-bearing rather than tidiness. With a naive select() that ignores its argument and returns the whole fixture, narrowing the middleware back to .select('banned') leaves all seven tests green — the fields arrive from the fixture, not from the query. Verified by mutation, both ways:

mutation	result
.select('banned username email role') → .select('banned')	4 of 7 red
req.user = { id, username, email, role } → req.user = { id }	4 of 7 red

The CONTROL: case stays green under both, by design — it guards against over-granting (role: 'admin' hardcoded), not against the defect.

a user row without a role leaves role undefined, not defaulted pins that absence stays absent: a default here would grant or deny on data the row does not contain.

Verification

• backend/__tests__/unit/middleware/ — 38/38, 7 suites
• backend/__tests__/unit/routes + controllers — 650/650, 99 suites
• tsc --noEmit — no errors in either touched file (pre-existing errors in scripts/ are untouched)
• npm run lint — the two remaining errors on the new file are the repo-wide import/no-unresolved + import/extensions pattern that every sibling middleware test carries

Not verified: no runtime exercise of /api/github/status or the registry routes against a live browser session — both findings are source-level plus the middleware unit test. I also did not count how many registry rows actually lack publisher.name; no Mongo read path from this seat.

Relates to #1211 (which fixes the registry sites at the consumer) and #809 (which touches /status but leaves :146 unchanged).

🤖 Generated with Claude Code