[quality] /hold cancel's no-label, failed-read and failed-removal arms in src/labels/hold.ts are unit-only #325

Finding

src/labels/hold.ts cancelHold has four arms that only the unit suite reaches; the bundle (end-to-end) suite never drives them through the committed dist/index.js:

The only existing bundle /unhold case (__tests__/bundle/bundle.test.ts, "removes do-not-merge/hold and the legacy hold label when /hold is configured") has both labels present and every write accepted; #293's holdSweepSettings covers the configured hold.label cancel, also with the label present.

Evidence (main @ 3fc21f2, Node v26, vitest 5.0.3):

• Unit: npx vitest run --coverage → src/labels/hold.ts 100 % lines (per-file unit coverage is saturated on this SHA).
• End-to-end: npm run test:coverage:e2e → src/labels/hold.ts 80 % lines (20/25), 81.81 % branches; src/utils/labeling.ts 73.07 % lines. Zero-hit statements read from coverage-final.json of that run.
• The two runs cannot be line-merged (different transforms, see [quality] the bundle e2e suite's coverage of src/ is never captured — runBundle.ts drops NODE_V8_COVERAGE and dist/ has no source map #235); the figures above are per-suite.

Recommendation

• Add a bundle suite (__tests__/bundle/holdCancelArms.test.ts) that runs /hold cancel, /unhold and /remove-hold with no hold label, with GET /issues/1 → 500, with the label DELETE → 500, and with one DELETE → 404, asserting exit status, the error cause and the exact request sequence.

Expected after the fix: src/labels/hold.ts e2e 96 % lines / 90.9 % branches — the remaining line is the missing-issue-number throw, which the API cannot produce.

Priority

• Impact: medium — covered by unit tests, not by the bundle suite (priority 2 per the coverage evidence rules)
• Effort: low

Filed by quality agent (hold-gated mode)

🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5q9t | SHA: 3586e39

— hive: agent=quality backend=copilot model=claude-fable-5.1 copilot=1.0.88