A GitHub run waiting for environment approval logs an "Unhandled workflow status: waiting" warning on every poll, flooding the 1000-entry log #306

What's wrong

MapWorkflowRunStatus (BuildMonitor/Providers/GitHub.cs:470-497) maps only Requested, Queued and InProgress explicitly. Octokit's WorkflowRunStatus also has Waiting and Pending. Waiting means a job targets a deployment environment with required reviewers and is waiting for approval. Both fall through to _ => RunStatus.Pending, which is the correct result. But the guard right after the switch then logs a Warning for any Pending result whose status isn't Requested or Queued:

Warning: GitHub: Unhandled workflow status: waiting, conclusion:  - treating as Pending

Why it matters

A waiting run counts as ongoing, so RunSync polls it every 10-60 s, and a deployment can wait for approval for hours. Each poll adds another identical warning. Log keeps only MaxEntries = 1000 (Log.cs:33), so after roughly a few hours of one pending approval, the genuine warnings and errors (auth failures, rate limits) have been pushed out. They are gone by the time someone opens the log to see what went wrong.

Repro

Build an uninitialized WorkflowRun with Status = new StringEnum<WorkflowRunStatus>(WorkflowRunStatus.Waiting), call MapWorkflowRunStatus (via reflection), and inspect Log.GetEntries().

• Observed: returns Pending, and one Warning entry is added per call.
• Expected: returns Pending with no warning, since this is a known, normal state.

Suggested fix

• Add explicit arms WorkflowRunStatus.Waiting => RunStatus.Pending and WorkflowRunStatus.Pending => RunStatus.Pending, and exclude both from the warning guard. The cleanest way is to make the guard fire only when the default arm was actually taken.
• If a warning is still wanted for a truly unknown status, log it once per distinct status value rather than once per poll.
• Add a test that Waiting and Pending map to Pending without adding a log entry.