Claude in Chrome tools never register in interactive sessions (work in `-p`); `/chrome` renders nothing

--chrome sessions never register browser tools (ToolSearch for chrome/browser/screenshot returns only WebFetch).

Debug log shows at startup:

[Claude in Chrome] Disabled: OAuth token has no scope accepted by /api/oauth/validate
(needs user:profile, user:office, or user:ccr_inference)

The session decides not to connect to the native-host bridge at all (confirmed via lsof — only the listener fd, zero accepted connections).

Ruled out: env-var/API-key auth (authMethod is real claude.ai OAuth), stale token (newest tokens already have user:profile scope), org-admin gate (Chrome extension enabled org-wide), stale process/OS state (reproduced post-reboot, single process), --resume, --dangerously-skip-permissions, native-messaging-host manifest ordering, and plain logout/login (scope unchanged after re-auth under two different orgs).

Best hypothesis: an account/product entitlement gap — Claude in Chrome may need separate enrollment beyond a standard Claude Code OAuth login, and re-login may be silently reusing an old consent grant that lacks the newer scopes.

Ask: is Claude in Chrome gated behind something beyond a standard Claude Code login? If so, what's the enrollment path, and can an existing OAuth grant be forced to re-prompt for the added scopes?