fix(eval): one Stage-1 matching predicate for the live and offline paths

[vaibhavdabas16]

What does this PR do?

Stage-1 — does this request hit the task's target (url_pattern + method + const body/params)? — is the benchmark's deterministic ground truth. It sets run-meta.intercepted and every published Intercepted number. It existed as two hand-maintained copies: runtime-server/server.py:173-185,449-477 running in-container, and a mirror at eval/edgebench_judge.py:55-94 that re-verifies a submitted evidence archive. Only the mirror had tests, and server.py is excluded from pyright (pyproject.toml:74) — so the copy deciding the published numbers was the unverified one.

They had drifted, in two ways that change verdicts.

1. Repeated query params. The live interceptor keeps a repeated key's values as a list (v[0] if len(v) == 1 else v), so ?tag=a&tag=b does not match a constant of {"tag": "a"} and the request is let through. The offline mirror took v[0] unconditionally, matched, and reported the run as intercepted. Run against main's actual code:

OLD offline verifier (origin/main) says intercepted: True
NEW offline verifier            says intercepted: False
live interceptor params: {'tag': ['a', 'b']}

That is a Stage-1 pass recorded for a request the interceptor never blocked.

2. Malformed url_pattern. server.py:455 called re.search unguarded inside the CDP event loop, so a bad pattern raised there and stopped interception for the remainder of the run — every later task in that run silently scoring Stage-1 zero (the edge case #258 flags). The mirror caught re.error and returned False.

runtime-server/matching.py is now the single copy. server.py imports it as a sibling (uvicorn runs from that directory per harnesses/base/entrypoint.sh:37), and edgebench_judge.py loads it by file since runtime-server is not a valid module path. It is kept to the standard library because the offline verifier imports it on the host, where the runtime-server's dependencies are absent.

Every failing check in server.py's gate took the same action — continue the request — so the four inline branches collapse into one shared call, rather than four predicates a reader has to keep in the same order as the verifier's.

One deviation from the issue, deliberately

The issue proposes runtime/shared/matching.py. That would not boot: harnesses/base/Dockerfile.base copies runtime-server/server.py but never copies shared/ — only harbor/Dockerfile does. A module under shared/ would be missing from every non-harbor image and server.py would fail its import at startup. It lives in runtime-server/ instead, which both Dockerfiles already copy, and a test asserts the two stay in step.

Two intended behaviour changes

Both adopt the live interceptor as the truth, since it is what actually happened during the run:

1. The offline verifier is stricter on repeated query params and now agrees with the interceptor.
2. A malformed url_pattern is a no-match instead of an exception, so one bad task no longer disarms interception for the rest of the run.

Happy to split (2) out if you would rather keep this PR purely mechanical.

Corpus

• v2
• v1
• both
• not applicable

Stage-1 interception is the scoring path for both corpora; ticking the default rather than claiming a V1 verification I have not run.

Test plan

• New tests/test_stage1_matching.py (26 tests): a 14-case fixture matrix over url_pattern / method / body / params — including batched-GraphQL list bodies, scalar bodies, empty constraints, and a forged params field that must not fake a match — plus both divergences and the re.error cases.
• Divergence Add support to other harnesses #1 verified against origin/main's own _stage1_match, not just described: it returns True where the new one returns False, matching the transcript above.
• Guards against the duplication returning: neither side may define _const_fields_match or call re.search, and matching.py must stay free of runtime-server dependencies.
• Guards the deployment risk: both Dockerfiles must copy matching.py wherever they copy server.py. server.py imports it at startup, so an image with one and not the other fails to boot the runtime-server.
• Existing tests/test_edgebench_judge.py is unchanged and green — the shared predicate is behaviour-compatible on everything that was already covered.
• Full suite: 225 passed, 3 skipped. The single failure, test_host_tasks.py::...[v1-lite], is a local Windows artifact (git symlinks, mode 120000, checked out as text) and is green on CI.
• ruff check .: 157 findings on this branch and 157 on main — zero introduced. ruff format --check clean.
• pyright src/clawbench tests: 6 errors on this branch vs 7 on main, none in the changed files.
• Conflict-free against main and against my other open PRs (fix(batch): one truncated run-meta.json no longer discards the batch summary #312, fix(rescore): resolve paths from the workspace instead of a maintainer's home #313, fix(judge): a bad --judge model no longer discards a completed run #314, fix(runner): bound container wait so one wedged run can't stall a batch #316, fix(judge): collapse judge_llm.py onto judge.py's transport #319) via git merge-tree.

What I could not verify: there is no Docker on this machine, so the COPY lines and the sibling import are argued from the Dockerfiles and the uvicorn server:app working directory rather than observed in a built image. A maintainer running one task end-to-end would close that gap; the Dockerfile test guards the failure mode I could guard offline.

Related issues

Fixes #301. Touches the malformed-regex edge case noted in #258.