Use GitHub issue events API to detect rule re-match within a single poll cycle

Currently, if a copilot session explicitly completes itself (via copilotd session complete), the CompletedBySession flag prevents re-dispatch. The flag is cleared when the daemon detects the issue no longer matches rules during a poll cycle. If a user toggles the issue state (e.g., removes and re-adds a label) within a single poll interval, the daemon never sees the 'unmatched' intermediate state and the flag remains set.

Proposed enhancement: During reconciliation, for Completed sessions with CompletedBySession = true that still match rules, use the GitHub issue events API (gh api repos/{owner}/{repo}/issues/{number}/events) to check for relevant state changes since the session's CompletedAt timestamp. Relevant events include:

• unlabeled followed by labeled (for label-based rules)
• unassigned followed by assigned (for user-based rules)
• demilestoned followed by milestoned (for milestone-based rules)
• closed followed by reopened

If such a sequence is detected, clear the CompletedBySession flag and allow re-dispatch, even if both changes occurred within the same poll cycle.

Tradeoff: One additional gh api call per completed-but-still-matching session per poll cycle. In practice this should be a small number of sessions.

Current workarounds:

1. copilotd session reset <issue> — immediate manual reset
2. Toggle the issue and wait at least one poll interval between changes

Start in the reconciliation path for Completed sessions where CompletedBySession and CompletedAt are checked. Read the GitHub issue events endpoint response and determine how to identify the listed change sequences after CompletedAt. Done means a relevant sequence clears the flag and permits re-dispatch while ordinary matching sessions remain unchanged.