feat(integrations): Bitbucket Cloud Pipe

GitHub has the Action and GitLab has a released CI/CD catalog component; Bitbucket Cloud is the
missing surface (Data Center has no Pipelines). The GitHub/Bitbucket asymmetry defines the work:

• Distribution: there is no pipe marketplace — pipe.yml's image: is a Docker Hub
  coordinate, and discovery is a curated Atlassian catalog reached by a manual process.
• Reporting: no GITHUB_TOKEN equivalent exists; the Pipelines auth proxy covers only the Code
  Insights API (BCLOUD-21842), so PR-comment/report parity requires a user-supplied token —
  document both tiers (with and without a token).
• Statuses: Bitbucket has no neutral build status, so the warned→neutral mapping used on
  GitHub needs an explicit decision (warned = successful-with-annotation, or failed).
• Gating: merge checks count successful builds; a named check cannot be individually
  required, and "prevent merge with unresolved checks" is Premium-only. The zero-config gate that
  works everywhere: --fail-on-error → exit 3 → the step fails → Pipelines records a failed build.
• Drift decision first: a Pipe would be the third copy of the Action's local-mode logic
  (GitHub Action, GitLab component, Bitbucket Pipe). Either upstream local mode into the Tirith CLI
  and make all three thin wrappers, or accept three copies and carry an anti-drift test that runs
  the same fixture through all three.

Acceptance. A sample Bitbucket Cloud repo runs the same policy set with the same verdict and
exit code as the GitHub Action, gating via the failed-build path with zero config; the
token-optional reporting tiers and the warned-status decision are documented; the drift decision is
recorded (and the anti-drift test exists if three copies is the answer).

The relevant entry points are pipe.yml, the existing GitHub Action and GitLab component local-mode logic, and the Tirith CLI. First resolve whether local mode is upstreamed or duplicated; then validate the Bitbucket Cloud acceptance case for matching verdict and exit code, zero-config failed-build gating, documented token tiers, the warned-status decision, and anti-drift coverage if duplication is chosen.