[scaree]

• Personal access tokens list the MCP write tools they may call (writeTools, empty = read only), fixed at creation; the management API (omitted or null = read only), PersonalAccessTokenFacade::create() and anzu:personal-access-token:create --write-tool=<name> (repeatable) accept them. Names are validated against the common-bundle MCP configuration (PersonalAccessTokenWriteTools constraint), a repeated name answers 422.
• Creating a token with write tools through the API needs the new auth_personalAccessToken_createWithWriteTools permission and answers 403 for a tool whose MCP tool permission the creator does not hold; the new GET personal-access-token/write-tools route lists the tools the user may grant. PersonalAccessTokenWriteToolResolver takes McpToolAccessChecker optionally, so applications without MCP keep working (read-only tokens only). The "Personal access token created." log carries the granted write tools. The README shows how a host declares the token permissions in permissions.config.
• PersonalAccessTokenAuthenticator copies the list onto the security token; McpToolWriteVoter grants the common-bundle mcp_tool_write attribute only for a tool listed on the token (not to a JWT/session, a super admin included).
• The auth cache prefix moves to pat_auth_token_v2.

Requires anzusystems/common-bundle#114 (^11.9 || dev-mcp_create_quiz until it is tagged). Hosts add a migration: ALTER TABLE personal_access_token ADD write_tools JSON DEFAULT NULL (nullable, because MySQL fills JSON NOT NULL with JSON null for existing rows). BC changes are listed in the CHANGELOG.