fix(evals): harden the agent-eval gate against LLM-judge flakiness

[pulzzejason]

Problem

The agent eval gate (live) flaked enough that real PRs were merged manually past it — eroding its real signal (genuine routing regressions: #1299's false 0.44, #1300). Root cause is structural: with an LLM judge that cannot be pinned deterministic (claude-opus-4-7 removed temperature — sending it 400s), a handful of borderline scenarios flip run-to-run and sink a hard aggregate bar.

Since this PR was first opened, main shipped the complementary half (G#350/G#352): the gate now asserts capabilityPassRate (capability scenarios only — canaries no longer inflate the denominator) against per-agent calibrated floors (evals/capability-floors.json; senior-pm 0.75 = its measured post-fix low at EVAL_SAMPLES=5). This PR is now merged with main and the two mechanisms compose: the floor calibrates where the bar sits; escalation removes the run-to-run variance around it.

Change (no new infra, judge model unchanged)

• decideScenario — flake-aware escalation (evals/judge/runner.ts): sample EVAL_SAMPLES (5); if unanimous, stop (the cheap common path); if split, resample in batches up to EVAL_MAX_SAMPLES (9), stopping early once a verdict is mathematically locked, then majority-decide. Cost stays ≈5 samples/scenario — escalation fires only on scenarios that genuinely disagree. Still-split-at-budget scenarios are logged ⚠ borderline (a human-look signal, not a gate failure).
• ci.yml: keeps EVAL_SAMPLES=5 (the floors' calibration basis — don't change one without the other) and adds EVAL_MAX_SAMPLES=9, both documented in place.
• agent-eval.test.ts: keeps main's floors-based assertions; the per-scenario cost cap now scales with EVAL_MAX_SAMPLES (an escalated scenario legitimately accrues up to 9 samples; the per-sample cap stays $0.50).
• eval-gate-stability.test.ts — committed regression canary, pure/offline (runs in eval-structure on every PR, no API key, even on fork PRs). Re-pinned to the floors semantics: escalation never rescues a consistently-failing scenario; a regressed senior-pm (6 routing scenarios broken → 0.70) trips its 0.75 floor; a default-floor agent with 3 consistent failures trips 0.9; canaries get no slack from the floor (one failing canary is red regardless); and a raise-only guard fails if anyone lowers the senior-pm floor below its measured 0.75 without consciously updating the evidence.
• evals/README.md: documents the escalation mechanism, how it composes with the floors, and the procedure for raising a floor from ≥2 measured live runs.

Acceptance criteria

• Merged with main, both mechanisms intact — escalation + capabilityPassRate/floors coexist; no scenario deleted, no canary weakened, no floor lowered.
• Catches real regressions — offline canary proves a regressed config trips its floor every run and escalation can't flip a real fail green.
• Cost bounded — only non-unanimous scenarios escalate; early-lock stops before the cap; cost cap scales with the escalation max.
• Post-merge live stability measured (task feat(engine): daemon-token goal PATCH can amend spec fields (Slice 1 of goal-spec parity) #1383): two live gate runs on the merged head both measured senior-pm capabilityPassRate exactly 0.80 (16/20) with an identical failure set (routing family orch-002/003/005/007) — variance eliminated, remaining failures consistent. Floor raised 0.75 → 0.80 (the measured low), evidence recorded in the floors note.

Out of scope (deferred)

Removing/advisory-fying the gate; rewriting agent prompts; baseline-relative regression infra; switching the judge model for determinism.

Agent config

No PM Agent config update needed — this changes the eval harness only (no tool added/removed, no change to agent-visible data, prompts, or workflows).

Validation

Offline agent-eval suite green in the worktree (293 passed, 30 live-skipped, EVAL_MODE=sample); npm run typecheck clean; diff vs main touches exactly the 5 eval-gate files.

Goal: de24de25