v0.10.57 — Fix multi-reviewer spurious reject

Bug Fix

Multi-reviewer unanimous approve was being converted to REJECT — every task using two reviewers (Claude + Codex) that both approved was incorrectly rejected, causing spurious re-coder cycles. In production this caused 5/6 rejections on well-implemented tasks.

Root cause: The needsMerge=false branch in resolveReviewerDecision was still calling invokeMultiReviewerOrchestrator, whose prompt unconditionally tells the LLM "The DECISION is already REJECT". The LLM correctly followed the prompt template and output DECISION: REJECT even when both reviewer notes said "Both reviewers approved."

Fix: When needsMerge=false, bypass the orchestrator entirely. Build the decision directly and deterministically from resolveDecision()'s output — no LLM call. The orchestrator is now only invoked for needsMerge=true (merging two or more reject checklists).

Additional improvements in the fix:

• Correct confidence levels per outcome (approve/skip=high, dispute/reject=medium, unclear=low)
• Correct push_to_remote (skip no longer set to push)
• For single-rejector reject: falls back to reviewer stdout (last 3000 chars) when parsed notes are a placeholder, so the coder gets the actual checklist
• Explicit unclear guard to handle ambiguous multi-reviewer results (approve+skip mix, empty results)

This fix went through 2 rounds of adversarial review (Claude + Codex) before and after implementation. Both reviewers approved the final implementation.

Compare: v0.10.56...v0.10.57