* fix(server): gate ref-resolver admin bypass on bearer auth (BUG-1618)
resolverWorkspaceRole returned "owner" for any platform admin regardless
of auth surface, so a bearer-borne admin (PAT / CLI / MCP) could probe
the existence of refs in workspaces they never joined via the /-/r/ 302
redirect — leaking workspace + ref existence plus the owner username and
collection slug in the redirect target.
Site 1 (real fix): thread isBearerAuth(r) into resolverWorkspaceRole and
gate the admin branch on !authIsBearer; the workspace-owner check stays
unconditional. Bearer-admins fall through to the member-then-grants check
(membership-only stance, matching BUG-1616/1617). Cookie-session admins
keep the owner bypass so the web-UI affordance is preserved. Added
TestRefResolver_AdminBearer_404OnNonMemberWorkspace (bearer -> 404) and
TestRefResolver_AdminCookie_StillRedirects (cookie -> 302).
Site 2 (audit, no logic change): the workspace sort-order bulk-update's
silent-skip needs no auth gate — UpdateWorkspaceSortOrder is scoped to
the caller's own workspace_members row, so a non-member PATCH touches
zero rows (no cross-ws write or leak), and handleListWorkspaces has been
membership-only for all authenticated users including admins since
BUG-982. Rewrote the stale comment to record both facts.
Parent: BUG-1617. Sibling: BUG-1616.
* fix(server): deny bearer-admin grant fallback in resolver per Codex review (round 1)
A bearer admin who isn't a member but holds a stray collection/item grant
got "guest" from resolverWorkspaceRole, then checkItemVisible's own
`user.Role == "admin"` bypass returned visible — reopening full resolver
access + 302 URL leakage the BUG-1618 fix was meant to close. Add the
membership-only guard (return "" for bearer-admin non-members before the
grant fallback), matching RequireWorkspaceAccess and the SSE/collab
sibling gates. New regression test TestRefResolver_AdminBearer_404EvenWithGrant.
xarmian
ae8173b42d