GHSA-m5qg-rvjq-727p

### Summary

The OAuth token strategy attached `oauth_scope` and `oauth_granted_resources` to the request user, but the ACL middleware never consulted either. An OAuth token issued with a restricted scope (e.g. MCP-only) therefore inherited the full permissions of the underlying user across all routes; the `granted_resources.base_id` restriction was bypassed on org-level endpoints that don't populate `req.context.base_id`.

### Details

In `packages/nocodb/src/strategies/oauth-token.strategy.ts`, the strategy set `is_oauth_token`, `oauth_client_id`, `oauth_granted_resources`, and `oauth_scope` on the user object, then mapped through to the user's existing `roles` / `base_roles`. The ACL middleware in `extract-ids.middleware.ts` honoured `is_api_token` via `blockApiTokenAccess` but had no equivalent gate for `is_oauth_token` or scope-string enforcement.

The base/workspace restriction logic short-circuited when `req.context.base_id` was unset (org-level routes), so an OAuth token scoped to one base could still call org-level endpoints as the underlying user.

The fix adds a path-prefix allowlist (`['/mcp', '/api/v3/', '/auth/user/me']`) enforced inside the strategy and a `blockOAuthTokenAccess` ACL flag for endpoints that should never accept OAuth tokens.

### Impact

- Scope escalation: tokens issued with a narrow scope received the underlying user's full role. - Resource boundary bypass: per-base restrictions did not apply to org-level routes. - Violates least-privilege expectation for third-party OAuth integrations.

### Credit

This issue was reported by [@ik0z](https://github.com/ik0z).