fix(build_pipeline): FIN-100g-4 deploy-parity must not rescue a malformed test run (H-1)

[urlmonitor]

Summary

Post-merge code review + logic check of the finalize-hardening work found a HIGH defect in the FIN-100g-4 deploy-parity self-check (introduced in #381).

H-1: a malformed Step-3 test-runner reply is treated conservatively as testPassed=false with an empty postMergeFailures. The deploy-parity block ran on any !testPassed; filtering an already-empty set left it empty, so testPassed flipped to true → triage/HALT skipped → merge on a malformed test run.

Fix

• Gate the block and the flip on postMergeFailures.length > 0 — an empty/ambiguous result can never be rescued to passed (H-1).
• M-2 contradiction guard: exclude a failure only if the agent reports it build-state AND not in still_failing (the still_failing field was previously ignored) — bounds trust in the classification; triage stays the sole authority that can HALT.

Test plan (behavioral — execute real JS via the E2 harness)

• H-1: empty failure set → deploy-parity is not dispatched.
• FIN-100g-4-i: a genuine failure survives exclusion → triage is dispatched (can HALT).
• M-2: a test in both build_state_only_failures and still_failing is not excluded.
• FIN-100g-3-i: source-order guard — the found:false return precedes the main-branch abort.
• 38 passed; ruff clean.

Residual (noted follow-up)

A well-formed-but-wrong agent reply is still trusted (M-1); full mitigation would forward the claim to triage as the sole clearing authority — a deeper FIN-100c change, out of scope for this fix.

🤖 Generated with Claude Code

[urlmonitor]

Superseded by #385 — the same H-1 fix rebased onto the new main that carries the BO-2500b proof-of-done workflow (#378). This branch predated that workflow so its required check could never report, and it could not be force-pushed in the current environment. Closing in favor of #385.