feat(bitbucket): add reject contract support

[KatalKavya96]

Summary

• Adds Bitbucket Cloud support for the backend-neutral reject(id, reason) -> ok change-request contract through pr reject <id> --reason-file <path>.
• Reuses the existing reviewed pull-request comment and decline primitives: the confirmed rejection reason is posted first, then the pull request is declined.
• Handles partial failure safely: if the reason comment succeeds but the decline fails, the command reports the partial outcome and directs the caller to inspect the PR before retrying, avoiding duplicate rejection comments. Bitbucket Data Center remains fail-closed.

Type of change

• Skill change (.claude/skills/<name>/) — eval fixtures updated below
• Tool / bridge contract (tools/<system>/*.md)
• Python package (tools/*/ with pyproject.toml)
• Groovy reference impl
• Cross-cutting (RFC, AGENTS.md, sandbox, privacy-LLM)
• Documentation (docs/, README.md, CONTRIBUTING.md)
• Project template (projects/_template/)
• CI / dev loop (prek, workflows, validators)
• Other:

Test plan

• prek run --all-files passes
• For Python packages touched: uv run pytest / ruff check / mypy passes
• For Groovy bridges touched: command-line invocation tested end-to-end
• For skill changes: eval suite passes for the affected skill
  (PYTHONPATH=tools/skill-evals/src python3 -m skill_evals.runner tools/skill-evals/evals/<skill>/)
• For skill behaviour changes: a new or updated eval fixture is included in this PR
  (a regression test for the bug fixed / the behaviour added — see CONTRIBUTING.md)
• Other:
  • focused reject backend / normalization / CLI tests pass
  • full Bitbucket test suite passes
  • git diff --check passes
  • workspace Ruff, formatting, mypy, pytest, sibling-script tests, validators, and spec checks pass

RFC-AI-0004 compliance

• HITL — the new reject mutation remains gated on explicit caller-side user confirmation
• Sandbox — no new unrestricted host access; the implementation reuses the existing guarded Bitbucket Cloud write path
• Vendor neutrality — Bitbucket-specific comment + decline operations are exposed through the generic reject(id, reason) change-request contract
• Conversational + correctable — agentic-override path documented if behaviour is adopter-tunable
• Write-access discipline — the bridge executes only the already-confirmed rejection reason and action; it does not autonomously decide to reject a pull request
• Privacy LLM — private content does not reach a non-approved LLM; redactor invoked where needed

Linked issues

Refs #606

Notes for reviewers (optional)

Bitbucket Cloud does not attach a rejection reason directly to the decline mutation, so the contract is implemented as two explicit steps:

1. post the confirmed rejection reason as a pull-request comment
2. decline the pull request

The rejection reason is validated as non-empty before any write.

If the comment succeeds but the decline request fails, the command raises an explicit partial-outcome error directing the caller to inspect pr discussion <id> and pr get <id> before retrying. This prevents a blind retry from duplicating the already-posted rejection comment.

Bitbucket Data Center reject writes remain unsupported in this follow-up to keep the change narrow.

[KatalKavya96]

Hi @potiuk — next narrow #606 follow-up after #1591.

This adds Bitbucket Cloud support for the backend-neutral reject(id, reason) contract via pr reject <id> --reason-file <path>.

The confirmed reason is posted as a PR comment first, then the PR is declined. If the decline fails after the comment was posted, the command reports the partial outcome and tells the caller to inspect the PR before retrying, avoiding duplicate rejection comments. Empty reasons are rejected before any write, and Data Center remains fail-closed.

Focused/full Bitbucket tests, Ruff, mypy, workspace pytest, validators, spec checks, and the full prek run --all-files suite are green.

[potiuk]

LGTM — reject reuses the reviewed comment and decline primitives, an empty reason is refused before any write, and a decline that fails after the reason was posted is reported as a partial outcome naming pr discussion / pr get, the same safe shape as post_review. ok requires both the comment and the declined PR, Data Center fails closed before any request, and the README and adapters.md record the new write. CI is green.

---

This review was drafted by an AI-assisted tool and
confirmed by an Apache Magpie maintainer. The maintainer
approving this PR has read the findings and signed off. If
something feels off, please reply on the PR and a maintainer
will follow up.

More on how Apache Magpie handles maintainer review:
Contributing guide.