feat(bitbucket): add read-only PR status fetch

[KatalKavya96]

Summary

• Adds magpie-bitbucket pr status <id> as a read-only Bitbucket change-request status operation.
• Fetches the pull request source commit first, then reads build/status results for that commit from Bitbucket Cloud or Data Center.
• Normalizes build/status output into partial-read-only status data with aggregate status, checks[], commit, and raw payloads, without adding any write or Pipelines 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: 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: verified targeted Bitbucket tests with PYTHONPATH=src uv run --group dev pytest tests/test_bitbucket.py

RFC-AI-0004 compliance

• HITL — any new mutation is gated on explicit user confirmation
• Sandbox — no new unrestricted host access; network reach declared in the adapter
• Vendor neutrality — extends the existing Bitbucket contract:change-request / Coverage: partial-read-only adapter without introducing Bitbucket-specific capability naming.
• Conversational + correctable — agentic-override path documented if behaviour is adopter-tunable
• Write-access discipline — this PR only reads PR source-commit build/status results and does not trigger, retry, approve, merge, comment, or mutate Pipelines/builds.
• Privacy LLM — fetched Bitbucket status descriptions and raw payloads remain external data and are emitted as read-only bridge output for the caller to handle under the existing privacy/approved-LLM rules.

Linked issues

Refs #606

Notes for reviewers (optional)

This is the next read-only Bitbucket follow-up after the PR discussion work.

The new command is magpie-bitbucket pr status <id>. It fetches the PR first to identify the source/latest commit, then reads build/status results for that commit:

• Bitbucket Cloud: commit statuses for the PR source commit.
• Bitbucket Data Center: build status results for the PR source commit.

This intentionally keeps the scope to read-only source-commit status checks. It does not trigger or retry builds, mutate Pipelines, post comments, approve/decline/merge PRs, or attempt full Pipelines workflow coverage.

[KatalKavya96]

Hi @potiuk , I opened the next Bitbucket follow-up PR for #606.

This adds magpie-bitbucket pr status <id> as a read-only status operation under the existing contract:change-request + Coverage: partial-read-only model.

The implementation now uses Bitbucket Cloud’s PR-native statuses endpoint, and for Data Center it fetches the PR source commit and reads build statuses through /rest/build-status/1.0/commits/{commitId} with pagination. The normalized output follows the change-request status shape with state, aggregate checks, mergeable, and detailed check_details[].

I also updated the Bitbucket README, spec-loop adapter docs, and labels/capabilities inventory so the documented coverage matches the new behaviour.

prek run --all-files is passing.