fix(auth): default-deny API-token route capabilities

[RaresKeY]

Summary

This replaces #5680, which GitHub closed during the repository transfer and fork-network separation. The branch has been rebuilt on the current dev history; the implementation scope is unchanged.

Refresh #3150 onto current dev and make bearer-token access default-deny at the middleware boundary. Valid ody_ credentials may reach only explicitly registered method/path capabilities with matching scopes; browser/admin, token-management, session, upload, shell, workspace, Cookbook administration, and other unregistered routes remain unavailable. Supported generic chat/model and unrelated Codex/Claude APIs keep their documented behavior. Only the three temporary companion discovery/model reads remain during this slice. Existing bearer access to generic session, history, upload, and stream routes is intentionally not carried into the explicit capability manifest; the final companion-removal draft then deletes the remaining /api/companion/* bridge.

This branch preserves Musaab Hasan's original authored capability commit from #3150, then reconciles the route inventory, owner-scoped model behavior, ASGI path normalization, production-middleware coverage, retired Cookbook scopes, and current tests. Existing tokens may retain legacy Cookbook strings, but those strings are inert and new tokens cannot mint them.

This draft follows #5678 and PR #5679, the focused implementation for #5676, and must merge before the companion-removal draft. After those prerequisites merge, this branch should be rebased and its temporary path/Cookbook overlap deduplicated before review for merge. It must not merge directly on current dev: until #5676 lands, the old token forms still submit the Cookbook scopes retired here.

Target branch

• This PR targets dev, not main.

Linked Issue

Fixes #3149

Part of #5674

Type of Change

• Bug fix (fixes a confirmed authorization gap; the compatibility break is marked below)
• New feature (non-breaking — adds explicit route capabilities)
• Breaking change (removes implicit bearer access to unregistered route families)
• Refactor / cleanup (behaviour unchanged)
• Documentation only
• CI / tooling / configuration

Checklist

• I searched open issues and open PRs and reviewed the existing draft Harden API token route capabilities #3150.
• This PR targets dev.
• My changes are limited to the API-token route/capability boundary and regressions found while validating it.
• I ran the full app interactively. This remains a draft until maintainer review and deployment-level verification are complete.

How to Test

1. Run python -m pytest -q tests/test_api_token_capabilities.py tests/test_api_token_middleware_integration.py tests/test_api_token_routes.py tests/test_api_token_user_route_gate.py tests/test_auth_policy.py tests/test_auth_regressions.py tests/test_session_owner_attribution.py. The isolated focused run passes all 126 tests.
2. Verify a chat-scoped token can call POST /api/v1/chat and GET /api/models, while the same valid token receives non-enumerating 403 responses on unregistered or wrong-scope routes.
3. Verify explicit bearer credentials do not inherit cookie/admin behavior or LOCALHOST_BYPASS, model inventory stays scoped to the token owner, and bearer requests cannot trigger endpoint refreshes.
4. Verify bearer calls to previously implicit session, history, upload, stream, shell, workspace, and token-management routes receive the same generic 403; this intentional compatibility break is why the companion-removal follow-up is part of the ordered stack.
5. Verify every /api/codex/cookbook/* request receives the generic 403 before its handler even when the stored token carries legacy Cookbook scopes, and verify new token creation rejects those retired scopes.
6. Run python -m pytest -q. The isolated full suite completes with 4,740 passing and 5 skipped tests. Its 12 failures exactly match the clean current-dev runner baseline: the omitted .env.example, one offline URL-join check, two backup-recovery checks, and eight offline web-fetch checks.

Visual / UI changes — REQUIRED if you touched anything that renders

Not applicable. No UI or rendering files are changed.