fix(server): use Bitbucket workspace permissions endpoint

[OliStarCooke]

What Changed

Bitbucket pull request permission checks now use the supported, workspace-scoped endpoint:

GET /2.0/user/workspaces/{workspace}/permissions/repositories

The server still filters the response to the requested repository and decodes the same effective admin, write, or read permission. The old HTTP 410 fallback was removed with the retired endpoint.

A regression test makes any request to the old endpoint fail with HTTP 404 and verifies that the supported endpoint succeeds. The existing authentication-failure coverage remains in place.

Why

Before every pull request write, PullRequestService asks the provider for the viewer's permissions. T3 Code used Bitbucket's removed /user/permissions/repositories endpoint for that preflight. Some Bitbucket accounts now receive HTTP 404 from the endpoint, so getViewerPermissions failed and the server never sent the requested comment.

The replacement endpoint reports the authenticated caller's effective repository permissions and accepts the existing read:repository:bitbucket API-token scope. Using it fixes the preflight without hiding real HTTP 401, HTTP 403, network, or response-decoding failures.

Closes #9034

Verification

• vp test run apps/server/src/pullRequest/BitbucketPullRequestApi.test.ts apps/server/src/pullRequest/BitbucketPullRequestProvider.test.ts — 47 tests passed
• Targeted formatting check passed
• Targeted lint passed
• Server typecheck passed; it reports only existing suggestions in unrelated files
• git diff --check passed

This was not tested by posting a comment to a live Bitbucket Cloud pull request.

Checklist

• This PR is small and focused
• I explained what changed and why
• UI screenshots are not applicable because this is a server-only change
• A video is not applicable because this does not change motion or interaction

Authored with gpt-5.6-sol via the Codex harness in T3 Code.

---

Note

Medium Risk
Touches preflight permission checks before Bitbucket PR writes; wrong endpoint or decoding could block comments/merges, though scope is limited to Bitbucket integration code with updated tests.

Overview
Bitbucket repository permission preflight now calls GET /user/workspaces/{workspace}/permissions/repositories instead of the retired /user/permissions/repositories route, using the workspace parsed from workspace/slug while keeping the same repository.full_name filter and permission decoding.

The HTTP 410 “endpoint removed” workaround is gone: getRepositoryPermission no longer treats a deprecated-endpoint response as “permission unknown → allow” and instead surfaces real API outcomes (e.g. 401 still fails the read).

Tests were updated to assert the new URL, exercise success via the workspace endpoint when other URLs would 404, and rename the auth-failure case accordingly.

^{Reviewed by Cursor Bugbot for commit da055cd. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Switch BitbucketPullRequestApi.getRepositoryPermission to workspace permissions endpoint

Replaces the deprecated /user/permissions/repositories call with /user/workspaces/{workspace}/permissions/repositories (workspace URL-encoded). The filter query and escaping behavior are unchanged.

• Removes the isRepositoryPermissionRemovedError helper and its special-case catch that treated an HTTP 410 from the old endpoint as an implicit grant.
• Updates tests to expect the new workspace-scoped URL and verifies that 401 failures still propagate as failures.
• Risk: errors from the new endpoint now propagate normally instead of a 410 being converted to true; callers of getRepositoryPermission that relied on the old 410-as-success behavior in BitbucketPullRequestApi.ts will see different results when the endpoint returns 410.

^{Macroscope summarized da055cd.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This focused server fix replaces a retired Bitbucket permissions endpoint and changes the permission preflight used for pull-request write capabilities. Because it modifies production access-control behavior, human review is warranted despite the small, tested diff.

^{You can add or adjust custom eligibility rules. Learn more.}