[Feature] Support BitBucket data center

[Kennybll]

Currently t3code only supports BitBucket Cloud. I am trying to use t3code at work, but we use BitBucket data center so the BitBucket integration does not work since it uses different endpoints.

[iOSDeveloperGuy]

+1 for this. We use a self-hosted Bitbucket Data Center instance on a custom internal domain, so this is currently the main thing keeping us from being able to use the Bitbucket integration fully.

For us, the most useful initial scope would be authenticating against a custom Data Center instance and supporting the normal PR workflow: create/view PRs, diffs, comments, reviewers, and merge/decline.

I'd also be happy to help test this against a real Data Center instance, or help with the implementation if that's useful.

[BerkayClik]

+1, we run Bitbucket Data Center too. (I opened #14592 for this by mistake; it was closed as a duplicate of this thread, so moving the details here.)

What differs from Cloud, for whoever picks this up:

• API: REST 1.0, /rest/api/1.0/projects/{KEY}/repos/{slug}/pull-requests/..., rather than Cloud's /2.0/repositories/{workspace}/{repo}/pullrequests/....
• Remote URL shapes: https://host/scm/{project}/{repo}.git and ssh://git@host:7999/{project}/{repo}.git.
• Pull request URLs: https://host/projects/{KEY}/repos/{slug}/pull-requests/{n}.
• Auth: instance-scoped HTTP access tokens (bearer), separate from any Bitbucket Cloud credential.
• Base URL: one per host, derived from the remote rather than one process-wide API root, so a Cloud token is never sent to a self-hosted instance (and vice versa).

A read-only first step (list / view pull requests, branch PR status) seems like a reasonable starting scope, with actions (comment, approve, merge) after that.

Related: today a Data Center remote is classified as Bitbucket and its PR traffic goes to api.bitbucket.org (#14591). #14593 stops that by marking such hosts unsupported until this lands.

[OhadC]

I've implemented this on a fork and would like maintainer sign-off on direction and scope before opening a PR: https://github.com/OhadC/t3code/tree/feat/bitbucket-data-center

Scope (tested against a real Data Center instance):

• Detection: remotes on a host with a bitbucket DNS label other than bitbucket.org are a separate bitbucket-server kind. This covers https://host/scm/KEY/repo.git, ssh://git@host:7999/KEY/repo.git, ~user personal repos, context paths, and Data Center PR URLs. They never reach the Cloud client, so this also fixes Self-hosted Bitbucket (Server/Data Center) remotes are treated as Bitbucket Cloud → useless api.bitbucket.org traffic; request Bitbucket Server support #14591.
• Auth: one instance, set by host URL plus an HTTP access token (bearer). Saved in Settings → Source Control, with the token in the secret store, the same way as Cloud credentials since feat: save Bitbucket credentials from Source Control settings #14103. T3CODE_BITBUCKET_SERVER_URL and T3CODE_BITBUCKET_SERVER_TOKEN are the fallback. It's separate from the Cloud credentials. Requests only go to the configured host, and a remote on a different host fails with a clear error, so neither token goes to the other service.
• Repositories: look up a repository, get clone URLs, and check branch PR status. Publish isn't offered.
• Pull requests: list, view, diff, timeline, checks, and the PR watch head SHA. Also create, comment, inline comments and replies, review (approve / request changes), reviewers, edit, and merge / decline / reopen. Reactions, thread resolution, and draft toggling aren't offered, through the existing capability flags.

Size: about 6.9k added lines, roughly half of them tests. Most of it is new adapter files beside the Cloud ones. Shared changes are small: the contract enum value, URL parsing, provider registration, and the settings form.

Splitting: happy to send it as a stack if that's easier to review:

1. detection (fixes Self-hosted Bitbucket (Server/Data Center) remotes are treated as Bitbucket Cloud → useless api.bitbucket.org traffic; request Bitbucket Server support #14591)
2. repository operations
3. reading pull requests
4. pull request actions
5. saved credentials

Or I can start with the read-only part, as suggested above.

Relation to #14593: it marks these hosts unsupported until Data Center support exists. This work replaces that by routing them to the Data Center adapter. If #14593 lands first I'll rebase on it.

Known limitation: one Data Center instance per server, and the host needs a bitbucket DNS label, the same rule detection uses today.

Does this direction and scope work for you, and do you prefer one PR or the stack?