test(evals): add technical-design bad pointwise fixtures

[aryeko]

Summary

• add one expected-bad pointwise calibration candidate for each technical-design public case
• add a deterministic regression test proving each committed bad candidate stays red and hits its targeted contradiction
• update curated calibration notes to distinguish committed expected-bad candidates from fresh provider evidence

Verification

• pnpm eval:unit -- --runInBand
• deterministic pnpm eval:case for all seven candidate-bad-pointwise.md files; each produced verdict red with the expected nonzero exit
• pnpm install --frozen-lockfile
• pnpm eval:doctor
• pnpm eval:list
• pnpm eval:validate-fixtures
• pnpm eval:judge:doctor
• pnpm eval:judge:list
• pnpm eval:judge:validate-fixtures
• pnpm check
• git diff --check

No provider-backed evals were run. Raw c4 evals/results bundles remain ignored/local.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3ee7c6b721

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Remove answer-key text from judged candidates

For these expected-bad pointwise fixtures, this defect section is part of the Markdown that the manual pointwise judge receives as the candidate, so the provider sees both that the file is intentionally bad and what contradiction to look for. That contaminates false-pass calibration: a judge can return red from the answer-key label/explanation instead of detecting a plausible semantic defect in the design itself. Keep this metadata outside the candidate file or strip it before pointwise runs.

Useful? React with 👍 / 👎.