source-control:babysit-prs: fetch-all-pr-comments.sh output needs PYTHONUTF8=1 to parse on Windows (emoji/cp1252 mismatch)

[kyle-sexton]

Lane: babysit (safe/gate tier), observed on #568.

fetch-all-pr-comments.sh JSON output failed to parse for a downstream Python consumer on this Windows machine until PYTHONUTF8=1 was set — root cause is Windows' default cp1252 stdout/stdin encoding choking on emoji/non-ASCII bytes (badge images, bot reaction emoji, etc.) commonly present in bot review comments (codex P1/P2 badges, claude[bot] reactions).

Category: bug (cross-platform). Expected: the script's own docs should either note the PYTHONUTF8=1 requirement for Windows consumers, or the script/its consumers should set it internally so callers don't have to discover it per-session.

Work-class: C3 (bug-fix-shaped) — attended triage 2026-07-23, operator-ratified. 🤖

[kyle-sexton]

This was generated by AI during triage.

T1 — routing status: ready. Clear, well-understood Windows cp1252-vs-UTF8 encoding gap, single script, no design decision — either document the PYTHONUTF8=1 requirement or set it internally so callers don't have to discover it per-session (implementer's call, both are mechanical).

[kyle-sexton]

This was generated by AI on operator direction.

Superseded — this item was already ratified and should not have been queued.

The earlier first-drain ratification request on this issue was raised in error. The admission gate dispatches a C3 bug-fix-shaped item when it carries either its own recorded ratification or a completed first drain — and this issue already carried recorded ratification in its body from attended triage on 2026-07-23. The drain cycle applied the blanket first-drain rule without first reading bodies for an existing ratification, so it queued an item that was already admitted.

Restored to the autonomous frontier: agent-ready re-applied, needs-human removed. No human action is required, and this issue no longer appears in the attended queue's ratify view.