[quality] withdrawalReason's 'and N more' tail (approveReview.ts:105) and no-withdrawer arm (:120) have no end-to-end coverage #407

Finding

Two arms of withdrawalReason (src/plugins/approveReview.ts:104-120), which builds the dismissal message of the mirrored approve.github_review review, are never driven through dist/index.js:

The existing bundle tests either short-circuit before withdrawalReason runs (approveReviewShortCircuits.test.ts: not-open, nothing-to-dismiss, no-files) or always include a /approve cancel comment and a single file, so only the withdrawn by … arm with ≤ 5 files is exercised.

Evidence (main @ 20d49e7, Node v26.10.0, vitest 5.0.3):

• Unit: npx vitest run --coverage → 100 % lines; __tests__/plugins/approveReview.test.ts:578-580 calls withdrawalReason directly for both arms.
• End-to-end: npm run test:coverage:e2e on a scratch branch = origin/main + the heads of all 14 open hold-gated bundle PRs (test(bundle): drive owners-label's early-return and failure arms through dist/index.js #298 … test(bundle): drive parseOwners's content-shape arms (owners.ts:39/41/83) through dist/index.js #406; 64 files, all pass) → 98.09 % lines of src/; approveReview.ts reports branches 63, 105, 120, 230 uncovered. Confirmed with --coverage.reporter=json: both branches on lines 105 and 120 have one arm at 0 hits.
• None of the open hold-gated PRs touches approveReview.ts arms (test(bundle): drive the approve plugin's evaluation arms through dist/index.js #333 claims src/plugins/approve.ts only).

Recommendation

• add __tests__/bundle/approveReviewReasonArms.test.ts running pull_request_review through dist/index.js against the fake GitHub with approve.github_review: true, the approved label set and the Bot's marker review present: (a) 7 uncovered files + /approve cancel → dismissal message … sdk/e.go and 2 more; withdrawn by bob (/approve cancel); (b) one uncovered file and no comments → approved removed: no approver covers sdk/x.go

Companion PR follows. Lines 63 (identity.login known, i.e. a user token) and 230 (errorMessage of a non-Error) are left out: 63 needs the GET /user success path inside the dismissal flow and is a separate cluster; 230 is a defensive coercion no API answer reaches.

Priority

• Impact: medium (unit-covered, no e2e coverage → coverage-gap priority 2)
• Effort: low

🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5q9t | SHA: 20d49e7

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