label-hygiene --apply fails the whole batch when one label is refused (HTTP 422), so a close event cleans nothing #1420

Written-by: Dev3

label-hygiene.mjs --apply removes labels one gh api -X DELETE at a time with no guard around the call, so the first refusal aborts the whole run before any read-back. On the first close event after #1404 merged, both runs did exactly that and cleaned nothing:

• issues run 40485666850 (2026-10-27T10:04:37Z, head 7a4fa61e) — failure
• pull_request_target run 40485663849 (2026-10-27T10:04:36Z, head 162d4bb5) — failure

Both logs, verbatim:

label-hygiene: before: 19 item(s) / 20 label(s) not open
#1356 Revert "feat(board): unify task and delivery boards into one view" -agent-pr
gh: Validation Failed (HTTP 422)
label-hygiene: Command failed: gh api -X DELETE repos/ThinkFlowLab/FlyBot/issues/1356/labels/agent-pr
gh: Validation Failed (HTTP 422)

##[error]Process completed with exit code 1

#1356 is a pull request, not an issue: closed 2026-10-27T06:21:18Z, agent-pr added 06:18:16Z. The same DELETE issued with the Bot's PAT answers 200, so the label was there and the refusal is specific to that call in that context — the script treats it as fatal regardless.

User-visible result: #1401 kept agent-working after it closed (10:04:34Z) and #1356 kept agent-pr, until they were removed by hand at 10:05:53Z and 10:07Z. So the trigger added by #1404 runs, and still leaves the board wrong — the exact defect #1404 was meant to close.

Fix

In the apply loop, per label:

• run the DELETE inside try/catch;
• 404 and 422 mean "not there any more" — print one skip line naming the item and the label, and continue;
• any other failure is collected, the remaining labels are still processed, and the run exits non-zero at the end naming those items;
• the existing read-back (after:) stays the verdict: a non-zero after: still fails the run.

Acceptance

1. A case with an injected gh that throws on one item: every other label still gets its DELETE, exactly one skip line is printed, and after: reads 0 — i.e. the 19 items of the repro clean the 18 the API accepts.
2. A failure that is neither 404 nor 422 still exits non-zero and names the item it stopped on.
3. hold and the record labels (bug, area:*, risk:*, status:done, needs-*) are untouched, as today.