feat(bitbucket): add read-only PR merge-checks fetch

[KatalKavya96]

Summary

• Adds magpie-bitbucket pr merge-checks <id> as a read-only Bitbucket pull-request merge-check context command.
• Normalizes conservative mergeability context from existing read-only PR, status, and review signals, including reported mergeability/conflict fields, status-check state, review decision, blockers, and raw backend payloads.
• Extends the existing partial read-only contract:change-request Bitbucket coverage after PR reviews/status, without adding any merge, approval, comment, branch, build, or other mutation path.

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: PYTHONPATH=src uv run --group dev pytest tests/test_bitbucket.py -q
• For Python packages touched: uv run --group dev ruff check src tests --fix
• For Python packages touched: uv run --group dev ruff format src tests
• For Python packages touched: uv run --group dev mypy src tests
• 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:

RFC-AI-0004 compliance

• HITL — no mutation behaviour is added; the new command is read-only
• Sandbox — no new unrestricted host access; Bitbucket network reach remains declared in the adapter
• Vendor neutrality — extends the existing Bitbucket contract:change-request / Coverage: partial-read-only adapter without introducing a Bitbucket-specific capability contract
• Conversational + correctable — agentic-override path documented if behaviour is adopter-tunable
• Write-access discipline — this PR only reads merge-check context and does not merge, approve, request changes, comment, edit branches, retry builds, or mutate repository state
• Privacy LLM — fetched merge-check decisions/blockers, reviewer/status context, CI URLs, and raw Bitbucket payloads remain external data and are emitted as read-only bridge output for the caller to handle under existing privacy/approved-LLM rules

Linked issues

Refs #606

Notes for reviewers

This follows the recently merged Bitbucket PR review-state command and targets the next PR-management gap: read-only mergeability / merge-check context.

The new command is:

magpie-bitbucket pr merge-checks <id>

It composes existing read-only PR status and review-state fetches with the PR payload, then normalizes conservative merge-check context:

• reported mergeable / can_merge / canMerge fields where exposed
• reported conflict fields where exposed
• status-check aggregate state
• review decision
• normalized blockers
• raw backend payloads

This intentionally does not claim complete Bitbucket mergeability parity. If the backend does not expose a clear mergeability or conflict field, the normalized output keeps that value as unknown instead of guessing.

This remains read-only. It does not add merge execution, comment posting, approvals, request-changes actions, branch edits, issue changes, build retries, or any other mutation path.

[KatalKavya96]

Hi @potiuk, I opened the next Bitbucket follow-up for #606 after the merged PR review-state command.

This PR adds a conservative read-only merge-check context command:

magpie-bitbucket pr merge-checks <id>

It composes the existing read-only PR status and review-state fetches with the PR payload, then normalizes merge-check context such as reported mergeability/conflict fields where exposed, status-check aggregate state, review decision, blockers, and raw backend payloads.

I intentionally kept this partial and conservative: if Bitbucket Cloud or Data Center does not expose a clear mergeability/conflict signal, the normalized output keeps it as unknown instead of guessing. This does not add any mutation path like merging, approving, commenting, requesting changes, editing branches, or retrying builds.

prek run --all-files and the targeted Bitbucket pytest/ruff/mypy checks are passing.

[potiuk]

Read-only merge-check composition over existing status/reviews signals plus the DC GET .../merge test endpoint — conservative "keep unknown rather than guess" normalization, consistent with the existing partial-read-only adapter. Green CI, solid test coverage. LGTM.