Split needs-human into two labels: routine 'needs-review' vs genuine 'needs-human' escalation

[robercano-ghbot]

Problem

The single needs-human label (issue #99 seam, .claude/scripts/needs-human.sh) is applied for two very different situations:

1. Routine, healthy waits on the owner — CI-green PR with no review yet (merge-ready.sh → kind pr-review, severity low), or changes-requested handoffs (pr-feedback.sh → kind changes-requested, severity low).
2. Genuine escalations — attempt budget exhausted, stall, rebase/comment-fix budgets, protected-paths block (kinds attempt-budget, stall, rebase-attempt-budget, comment-fix-thread-budget, protected-paths; all severity high).

Because one label covers both, its description ("blocked on owner judgment") reads as an alarm even on a perfectly healthy PR that's merely awaiting review. Concrete confusion today (2026-07-24): PR #191 was green across all 9 checks and simply waiting for owner approval, but the needs-human label made it look like the loop had failed and escalated.

Proposal: two labels, routed by the SEVERITY argument the seam already receives

needs_human_flag TARGET KIND SEVERITY TITLE BODY already takes severity from every caller, and severity already partitions the two cases perfectly (low = routine wait, high = escalation). So:

• needs-review (yellow, e.g. fbca04) — description: "CI green — waiting on owner review/approval". Applied when severity is low.
• needs-human (keep red b60205) — description: "Loop escalated: blocked, manual triage required". Applied when severity is high.

Implementation notes (all inside the existing seam — callers unchanged)

• needs_human_flag: pick the label name from $severity (low → needs-review, else needs-human). Idempotent-create BOTH labels via the existing REST POST (gh 2.4.0 has no gh label, per issue needs-human: every label write silently no-ops (gh 2.4.0) — episode guard never arms, one PR comment per tick (99 spam comments on PR #168) #169 — keep everything on gh api).
• Episode detection (_needs_human_already_labeled) must check for the label being applied now, not hardcode needs-human, so fresh-episode/comment-suppression semantics (issue needs-human: every label write silently no-ops (gh 2.4.0) — episode guard never arms, one PR comment per tick (99 spam comments on PR #168) #169's confirmed-before-comment invariant) keep working per label.
• needs_human_clear: DELETE both label names (a 404 is already the expected steady state), so callers don't need to know which flavor was set — this keeps merge-ready.sh's belt-and-suspenders clears on merge working without signature changes.
• Update the repo's existing needs-human label description via REST so the hover text stops claiming "attempt budget exhausted" for routine cases.
• Tests: extend needs-human.test.sh to cover severity→label routing and clear-removes-both.

Out of scope

Caller-side changes — the whole point is that the seam's signature (TARGET KIND SEVERITY TITLE BODY) already carries the routing information.