Add remaining open eval cases from the 25-case proposal

[justsml]

Description

This PR started as a proposal document (evals/PROPOSED_NEXT_25_CASES.md) turning TODO.md's eval-dataset-audit gap list into 25 concrete case proposals. While drafting the implementation, it turned out commit bb64abc had already landed ~20 of those 25 rows directly on main. This PR now:

1. Reconciles the docs — evals/PROPOSED_NEXT_25_CASES.md and TODO.md are updated to mark each of the 25 items DONE / DONE (merged) / OPEN against what's actually in datasets.ts today.
2. Implements the ~5 genuine remaining gaps:
   • oauth-redirect-symptom / oauth-sso-redirect-validation and business-logic-symptom / business-logic-checkout-abuse — the two vulnerability classes still missing from the anonymous attack-vector and Juice Shop lanes (evals/attack-vectors.ts, src/mastra/evals/datasets.ts, scripts/live-evals/juice-shop-eval-config.ts).
   • Two patch-diff-blind scenarios and one remediation report-writing scenario, covering the north-star loop's remediation/report legs (new src/mastra/evals/patch-diff-scenarios.ts and src/mastra/evals/report-writing-scenarios.ts, registered in datasets.ts, wired into canonical-schema.ts's artifact/mode/environment mapping). These are prompt-only rows — there is no live repo-checkout runner for patch-diff-blind yet, and the dataset description says so.
   • A benchmarks/exploit-hunter/second-webapp pack scaffold for target diversification (item [Tier 3] Create logo and brand identity #18 in the audit). It intentionally fails closed: the obvious second-target image bakes its own well-known branding into server-rendered HTML with no runtime theming hook, so serving it as-is under an anonymous target-disclosure claim would leak the benchmark's identity to the model under evaluation — the exact contamination failure mode the Eval Honesty Rules exist to prevent. init_script.sh/start_docker.sh exit non-zero with an explanation; the README documents the follow-up work (a Dockerfile that neutralizes the branding) needed before it's usable.
3. Updates dependent tests — hardcoded dataset-name and scenario-id lists in tests/security-chat/eval-datasets.test.ts and tests/security-chat/juice-shop-eval-scripts.test.ts, plus the CI regression-gate baseline in evals/ci-regression-baseline.json (13→15 datasets, 123→130 canonical rows) and its test.
4. Moves the webapp-vulnerability-count/webapp-finding-quality scorers to an LLM judge. These two scorers previously counted vulnerability classes against a fixed 8-keyword regex taxonomy that never kept pace with the dataset's growth to 20+ classes — a correct SSTI or business-logic finding scored as if the response found nothing. They're now backed by an LLM judge (src/mastra/evals/webapp-scorers.ts) that identifies an open-ended list of distinct vulnerability classes, marks each evidence-backed or not, and scores diversity/evidence-grounding/context-adherence/drift-avoidance. Both scorers share one cached judge call per response to stay mutually consistent and avoid double billing. Same scorer ids/registration as before, so no other wiring changed; the deterministic helpers they used to call directly (countVulnerabilityFindings, assessWebappQuality, scoreWebappResponse) are untouched since they're also used for synchronous report fields elsewhere and are covered by existing tests.

Type of change

• New feature (non-breaking change which adds functionality)
• Documentation update

How Has This Been Tested?

• pnpm typecheck passes
• pnpm build passes
• pnpm test passes (full tests/security-chat suite: 178 files / 1081 tests)
• pnpm eval:ops:audit passes (0 errors; only pre-existing cybench raw-pack warnings)
• pnpm eval:publish:audit passes (0 errors; warnings are the expected "unreviewed row" / one pre-existing cybench duplicate)
• Manual testing steps: verified the new judge-backed scorer module imports without side effects (no network/API-key requirement at import time — the OpenRouter client and judge call are only constructed lazily when a score is actually requested). Could not run a live judge call in this environment (no OPENROUTER_API_KEY configured); the implementation mirrors the already-in-production plan-actionability-llm-judge scorer's model-selection pattern.

Checklist

• My code follows the style guidelines of this project (see AGENTS.md) — matched existing scenario/dataset authoring conventions exactly (symptom-described prompts, canonical schema fields, benchmark pack file shape, LLM-judge scorer pattern from plan-creation-scorers.ts)
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation (TODO.md, PROPOSED_NEXT_25_CASES.md, new pack README)
• My changes generate no new warnings (beyond the pre-existing ones noted above)
• New and existing unit tests pass locally with my changes

Security Considerations

The new second-webapp benchmark pack is designed to fail closed rather than risk starting a target that leaks the benchmark's identity to the model under evaluation (a contamination/scope-realism concern, not a traditional security vulnerability). No product runtime code, approval gates, or sandboxing paths were touched. The new judge-based scorer only reads already-generated eval output text and calls OpenRouter with a judge model; it does not execute or influence anything in the runtime security-research agent.