Defer merge queue evaluation when GitHub mergeable is Unknown

[iamnbutler]

Summary

• Adds mergeable_unknown flag to MergeQueueEntry to track when GitHub hasn't computed mergeability yet
• reconcile_merge_queue now sets this flag when mergeable is Unknown or None, and clears it when GitHub resolves to Mergeable or Conflicting
• Orchestrator evaluation logic (needs_eval and queue seeding) skips entries with mergeable_unknown=true, preventing premature approval of PRs whose conflict status is pending
• The flag is transient (not persisted to SQLite) — it's updated on each GitHub poll cycle, matching the lifecycle of the mergeable computation

Test plan

• Existing merge queue tests pass
• New tests verify mergeable_unknown defaults to false and entries with the flag still appear in pending() (filtering happens at orchestrator level)
• Manual: push a commit to a PR in the merge queue, verify the entry isn't evaluated during the brief window where GitHub returns Unknown

Closes #503

🤖 Generated with Claude Code

[iamnbutler]

Orchestrator Evaluation: Rejected

The PR has merge conflicts (Mergeable: No) and CI is failing. Beyond that, the implementation approach is reasonable — it adds a mergeable_unknown flag to MergeQueueEntry, sets it during reconcile_merge_queue when GitHub returns Unknown or None for the mergeable field, and gates evaluation in the orchestrator loop on this flag being false. The logic correctly defers evaluation until GitHub resolves mergeability, and the flag is cleared on the next reconciliation cycle when GitHub returns a definitive state. However, the PR cannot be merged in its current state due to conflicts and CI failures.

---

Feedback for agent:
The PR has merge conflicts and CI is failing — it cannot be merged as-is. The branch needs to be rebased/updated against main to resolve conflicts, and CI must pass before this can be approved.

The implementation logic itself looks sound: treating Unknown and None as 'defer evaluation' is a reasonable approach to issue #503. A few minor observations for when the conflicts are resolved:

1. The approach of treating None (no mergeable data at all) the same as Unknown is conservative but reasonable — if GitHub hasn't provided mergeable info, deferring is safer than proceeding.
2. The flag is correctly updated on every reconciliation cycle, so once GitHub resolves the mergeability check, the entry will be unblocked on the next poll.
3. Tests are minimal but appropriate for the model-level changes.