Document granular token boundary authorization rules

What does this MR do?

Records how granular personal access token authorization resolves its boundary, and the rule the Authorization group agreed on for endpoints that write to a second resource named in a request parameter.

• Adds doc/development/permissions/granular_access/authorization_principles.md. A token permission names the operation an API caller asked for, not the DeclarativePolicy abilities the service layer checks internally. The token is checked against the resource in the request path. A second resource named in a request parameter gets no separate token check. Each rule includes its reasoning so it can be linked during review instead of re-argued per endpoint. A fourth section separates this from a boundary that resolves the wrong resource, which is still a bug.
• Links the new page from the granular access index.
• Corrects doc/auth/tokens/fine_grained_access_tokens.md, which claimed a token can "only access the specific resources and permissions you define". Adds a section describing the two checks that run on every request, and the case where an operation writes to a project you did not select.

The additional_scopes framework added in !249562 (merged) would have required a second permission on the target of an issue move. No endpoint adopted it. Requiring create_work_item on a move target gives the token all 35 raw permissions in that assignable group on the target project for the token's lifetime, and no narrower grant exists, so the requirement costs more than the write it prevents. Removing the framework is separate work.

Draft until PSIRT confirms the stance.

Related issues

The reports that prompted this decision are confidential, so they are not linked here. The design discussion took place on the corresponding security merge request.

Author's checklist

• Follow the Documentation process, Documentation guidelines, and Style Guide. Vale and markdownlint pass with no warnings.
• Product availability details for the new page. Not applicable. The style guide excludes /development pages from availability details.
• Request a review from the Technical Writer assigned to Software Supply Chain Security, Authorization.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for.
    • The headings (other than the page title) should be active.
    • Any task steps should be written as a numbered list.
• Review by assigned maintainer, who can always request/require the reviews above.

🤖 Generated with Claude Code