fix: read the PR number from the event payload, not only from GITHUB_REF

[Ostico]

The failure

A pull_request run whose GITHUB_REF is not refs/pull/<number>/merge aborts with

::error::Could not determine PR number from GITHUB_REF.

and exit 1 — before Layer 1 measures anything. From the author's side that is indistinguishable from a coverage verdict: the required check goes red having never looked at the diff.

Observed 2026-08-12 on Ostico/bruno-mcp-studio#180. Editing the PR body fired the edited activity type, which produced a second run on a head sha whose earlier run was green. That second run failed this way, and because GitHub surfaces the latest run per check name, the merge button showed a red required gate for a commit that had already passed.

The change

.pull_request.number is present in every pull_request payload, for every activity type. GITHUB_REF carries the number only while GitHub has a merge ref to point the run at.

So parse_config now reads the payload at GITHUB_EVENT_PATH first and keeps GITHUB_REF as the fallback — every case that worked before still works.

_pr_number_from_event returns None rather than raising for anything unexpected: no GITHUB_EVENT_PATH, an unreadable or malformed file, a payload for another event, or a number that is not an int. That last one is not paranoia — true is valid JSON in that position and bool is an int subclass, so a plain isinstance(number, int) would accept it and pass True downstream as PR number 1. Each of these cases still has GITHUB_REF to fall back on, and raising would turn a recoverable run into a failed one.

main.py's message now names both sources it tried and states that nothing was measured. As written it pointed the reader at GITHUB_REF even once the payload was being consulted.

One existing test changed, deliberately

test_pr_number_from_env set GITHUB_REF and asserted 42. This suite runs inside Actions, where GITHUB_EVENT_PATH points at a real payload naming a real PR — so reading the payload first would have made that test measure CI's own PR number. It would have passed locally and failed in CI. It now unsets GITHUB_EVENT_PATH explicitly, with a comment saying why.

Verification

12 tests added (47 in test_config.py, 455 in the suite). ruff check src/ tests/ clean.

Mutation-checked — each of these turns the suite red:

Mutation	Result
never consult the payload	2 failed
let the ref win over the payload	1 failed
accept a non-int number	2 failed
let a malformed payload raise	2 failed

What this does not do

Consumers pin ostico/test-guard@v2, so merging changes nothing for them. The fix reaches bruno-mcp-studio only when the v2 tag moves to include this commit — a deliberate act, not done here.

[github-actions]

🧪 Test-Guard Report

✅ PASS — All changed source files have adequate test coverage.

Coverage Analysis: ✅ PASS

Changed lines: 100.0% covered (threshold: 100%)

📋 2 files: 2 ✅ pass

File	Verdict	Reason
src/config.py	✅ pass	100% diff coverage ≥ 100% threshold
src/main.py	✅ pass	100% diff coverage ≥ 100% threshold

Result: ✅ PASS