Guard MCP specs against api-scoped token assumptions

What does this MR do and why?

The MCP endpoint declares allow_access_with_scope :mcp, but create(:personal_access_token) defaults to [:api]. A spec written with the default agrees with any code that resolves identity through an api-scoped lookup, so neither catches what real clients hit. This came out of a bug found in review on !257035 (merged), where an mcp-only token resolved no requester at all.

Two changes, both guidance rather than behaviour. The gitlab-mcp-tool-builder skill now says which token to authenticate with. The authentication-testing principle, which already carries the narrowest-scope rule, now applies to the MCP request specs and the throttle specs that resolve a requester from a token, instead of only auth-team-owned paths. The globs go in both the manifest and the Authentication Test Quality Duo Code Review fence, because the distiller keeps the fence's hand-authored fileFilters when it reconciles.

References

• Bug that prompted this: !257035 (merged)
• Issue: #629883 (closed)

Screenshots or screen recordings

No UI changes.

How to set up and validate locally

1. Confirm the four added globs match real spec files:

   ls spec/requests/api/mcp/ ee/spec/requests/api/mcp/
   ls spec/requests/labkit_rack_rate_limit_spec.rb ee/spec/requests/labkit_rack_rate_limit_spec.rb

2. Run the two checks the pre-commit hook runs for these files:

   scripts/lint-ai-principles-manifest.sh
   scripts/lint-duo-review-instructions.sh

3. Confirm the claim the skill bullet makes — the endpoint accepts an mcp-scoped token and the factory does not default to one:

   grep -n 'allow_access_with_scope' lib/api/mcp/base.rb
   grep -n 'scopes {' spec/factories/personal_access_tokens.rb

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.