feat(tools): Add project management tools

[dcramer]

Project management is now a catalog-scoped skill with tools to create projects, update project metadata, and manage team access. create_project always returns a usable SENTRY_DSN, can link an existing repository by creating a root code mapping, and preflights repository matches before writing a project. update_project is limited to metadata, while add_team_to_project and remove_team_from_project handle team access with duplicate and last-team safeguards.

The Sentry API helpers now cover project team pagination, active client-key selection, repository lookup, and organization bulk code-mapping creation. Specs, docs, mocks, and client tests were updated with the implementation, and Sentry API mocks are scoped to Sentry hosts instead of wildcard domains.

Agents should migrate team membership changes away from update_project to the explicit team-access tools. The stdio CLI also accepts --all-skills for local access to catalog skills during development.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b380912. Configure here.}

[sentry-warden]

update_project declares idempotentHint: true but slug renames are not idempotent (packages/mcp-core/src/tools/catalog/update-project.ts:72)

In update_project's annotations, idempotentHint: true is declared, but the tool accepts an optional slug parameter that renames the project. After a successful rename the project is only reachable at the new slug, so a retry of the identical call (still keyed on the original projectSlug) resolves to a missing project and fails rather than being a no-op. Because the safety hint applies to the whole tool and a slug-changing call is not repeatable without a different effect, the hint should be set to false (or removed) to be conservative. Name/platform-only updates remain idempotent, but the hint must reflect the worst-case argument set.

Evidence

• inputSchema.slug (defined via ParamProjectSlug, lines 62-67) accepts a new slug that renames the project through apiService.updateProject.
• The handler passes slug: params.slug to updateProject (line 75); on success the project is only addressable at the new slug and projectSlug (old slug) is invalidated.
• A retry with the same arguments looks up the now-nonexistent old projectSlug, so the second invocation errors instead of being a no-op — contradicting idempotentHint: true at line 72.
• The tool already declares destructiveHint: true, so the idempotent claim is the inconsistent hint for slug-changing calls.

_{Identified by Warden mcp-audit}