[Verifier v2] Phase 3: Multi-Model Comparison Mode

[stranske]

Why

Different LLM providers may have different strengths in code evaluation. Running the same evaluation through multiple models and comparing results provides:

• Higher confidence when models agree
• Unique insights from different perspectives
• Ability to identify model-specific blind spots

Scope

Implement verify:compare mode that runs evaluation across multiple LLM providers and generates a comparison report.

Non-Goals

• Adding new LLM providers (use existing provider chain)
• Weighted voting or automatic verdict resolution
• Real-time streaming comparison

Tasks

• Create comparison runner in scripts/langchain/pr_verifier.py or separate module
• Implement sequential provider execution with result collection
• Build comparison report formatter (agreements, disagreements, unique insights)
• Update workflow to handle mode=compare with multi-provider execution
• Create comparison comment template (Markdown table format)
• Add tests for comparison logic

Acceptance Criteria

• Adding verify:compare label to merged PR triggers multi-model evaluation
• Runs evaluation through at least 2 providers (GitHub Models + OpenAI)
• Comparison report shows:
  • Areas of agreement between models
  • Areas of disagreement with each model's position
  • Unique insights from each model
  • Confidence levels per model
• Report posted as PR comment
• Graceful degradation if only one provider available

Implementation Notes

Depends on Phase 2 (#580) being complete.

Example comparison output:

## Provider Comparison Report

### Agreement (Both providers)
- ✅ Correctness: Implementation correctly addresses requirements
- ✅ Tests: Adequate coverage for core functionality

### Disagreement
| Dimension | GitHub Models | OpenAI |
|-----------|--------------|--------|
| Quality | 4/5 | 3/5 - "Could use more comments" |
| Risks | Low | Medium - "Edge case in line 42" |

### Unique Insights
- **GitHub Models**: Noted potential performance issue
- **OpenAI**: Suggested alternative algorithm

See design doc: docs/plans/agent-verifier-v2.md

[github-actions]

Branch codex/issue-581 created from main.

Option 1 (Invite) is enforced on issue events. PR creation is disabled by design so you are the PR author. Codex only engages on human-authored PRs.

Please open the PR as the author so Codex can work on it:

• Compare link: https://github.com/stranske/Workflows/compare/main...codex/issue-581?expand=1
• Suggested title: Codex bootstrap for #581
• Suggested body (copy/paste):

<!-- meta:issue:581 -->

@codex Your objective is to satisfy the **Acceptance Criteria** by completing each **Task** within the defined **Scope**.

## Keepalive Next Task

**This round you MUST:**
1. Implement actual code or test changes that advance at least one incomplete task toward acceptance.
2. Commit meaningful source code (.py, .yml, .js, etc.)—not just status/docs updates.
3. Mark a task checkbox complete ONLY after verifying the implementation works.
4. Focus on the FIRST unchecked task unless blocked, then move to the next.

**Guidelines:**
- Keep edits scoped to the current task rather than reshaping the entire PR.
- Use repository instructions, conventions, and tests to validate work.
- Prefer small, reviewable commits; leave clear notes when follow-up is required.
- Do NOT work on unrelated improvements until all PR tasks are complete.

**COVERAGE TASKS - SPECIAL RULES:**
If a task mentions "coverage" or a percentage target (e.g., "≥95%", "to 95%"), you MUST:
1. After adding tests, run TARGETED coverage verification to avoid timeouts:
   - For a specific script like `scripts/foo.py`, run:
     `pytest tests/scripts/test_foo.py --cov=scripts/foo --cov-report=term-missing -m "not slow"`
   - If no matching test file exists, run:
     `pytest tests/ --cov=scripts/foo --cov-report=term-missing -m "not slow" -x`
2. Find the specific script in the coverage output table
3. Verify the `Cover` column shows the target percentage or higher
4. Only mark the task complete if the actual coverage meets the target
5. If coverage is below target, add more tests until it meets the target

IMPORTANT: Always use `-m "not slow"` to skip slow integration tests that may timeout.
IMPORTANT: Use targeted `--cov=scripts/specific_module` instead of `--cov=scripts` for faster feedback.

A coverage task is NOT complete just because you added tests. It is complete ONLY when the coverage command output confirms the target is met.

**The Tasks and Acceptance Criteria are provided in the appendix below.** Work through them in order.

<!-- 
  DO NOT ADD TASK CONTENT BELOW THIS LINE
  
  Task content is dynamically injected from the PR body via the `appendix` input.
  This template file should only contain instructions, not PR-specific tasks.
  
  If you see task content in this file, it was incorrectly committed and should
  be removed. The guard script will flag this as an error.
-->