Fail loudly when an identity filter has no GithubUsername

[C-Hipple]

Summary

Follow-up to #196, which fixed re-review requests being dropped but left a second way for the "Waiting on Me" section to come up empty: FilterWaitingOnMe compares every PR against config.GithubUsername, and when that value is empty every comparison is against "". The filter matches nothing, returns an empty list, and the section stays empty with nothing in the log to say why.

FilterMyPRs and FilterMyReviewRequested fail the same way. FilterNotMyPRs inverts it and quietly matches everything, which is why a config with no username can look like it mostly works while exactly one section goes dark.

RawWorkflow.GithubUsername made this easy to hit. config.parseConfig has always defaulted it from the root-level setting and the config writer round-trips it, but no filter ever read it — so setting GithubUsername inside a [[Workflows]] block rather than at the root produced precisely one symptom: a single empty section.

Changes

• Identity filters (FilterWaitingOnMe, FilterWaitingOnAuthor, FilterMyPRs, FilterNotMyPRs, FilterMyReviewRequested) take their login as a parameter; workflows bind it at build time from the workflow's effective GithubUsername. A per-workflow username now does what the config schema implies, and an unset one fails the workflow build with a message naming the filter instead of silently matching nothing.
• ValidateWorkflows reports the same problem, so the config editor rejects it before writing the file.
• main runs config.Validate + workflows.ValidateWorkflows at startup and logs every problem. A hand-written config had never been validated — the RPC path only checks configs it is about to write — so typos in Repos, filter names, or PRState previously surfaced only as sections that didn't fill.
• FilterWaitingOnMe logs candidates/matched counts once per cycle.
• New cmd/debug_waiting_on_me: prints the resolved username, the workflows using the filter, any config problems, per-repo fetch errors, and one row per open PR with its requested reviewers and the reason it did or didn't match.

The per-repo fetch errors are worth calling out separately: hasUnfetchedRequirements skips a workflow for the entire cycle when any of its repos fails to fetch, so one inaccessible repo in the inherited global Repos list empties that section as items expire while narrower workflows keep working.

Test Plan

• go build ./... passes
• go test ./... passes
• New coverage: BuildFiltersList rejects an identity filter with no username and accepts a per-workflow one; ValidateWorkflows reports both the filter and ListMyPRsWorkflow cases; explain in the debug command is table-tested against primed interaction state (no API calls).
• Ran cmd/debug_waiting_on_me against a scratch config reproducing the reported setup — with GithubUsername unset it names the problem and exits; with it set it resolves the workflow and repo list. Live per-PR output needs a CRS_GITHUB_TOKEN, which this environment doesn't have.

---

Generated by Claude Code