Fix double-counted leave on withdrawal-during-edit, and 500s on a stale leave-type id

[karlitschek]

Two bugs found while reading through the workflow code. One commit each; both regression tests were confirmed to fail without their fix.

1. A withdrawal during a pending edit counted the same leave twice

Only one edit may be in flight per approved request, and createSuperseding() enforces that. Nothing enforced the other half — the two rules did not compose:

1. R1 is approved (say 5 days). The employee edits it → R2 PENDING, supersedes_id → R1.
2. The employee then withdraws R1 → WITHDRAWAL_PENDING. No check fired.
3. The manager approves R2 → retireSuperseded() required the original to be APPROVED, found WITHDRAWAL_PENDING, and returned null. R1 was never retired.

R1 then contributed 5 days to pending while R2 contributed its full days to used — the same leave counted twice. BalanceService's netting could not help: it only nets while the superseding request is itself pending.

Worse, declining the withdrawal afterwards returned R1 to APPROVED, leaving two overlapping approved requests on the same dates, both counted and both on the calendar — exactly the invariant RequestService's class docblock documents itself as protecting.

Fixed at both ends. cancel() now refuses to start a withdrawal while an edit is pending, reusing the message assertNoPendingEdit() already gives — cancel the edit first, then withdraw. And retireSuperseded() now treats WITHDRAWAL_PENDING as still in force alongside APPROVED, so a pair written before this guard still retires cleanly instead of double-counting forever.

Retiring an original now also dismisses its notifications: it is closed, so a withdrawal request against it would otherwise sit in the manager's list offering to withdraw leave that no longer exists.

2. A stale leave-type id answered 500 instead of 422

LeaveTypeMapper::find() throws DoesNotExistException, which is not an AbsenceException, so ApiControllerTrait never recognised it — an HR form left open while somebody else removed the type answered "An unexpected error occurred" with a 500 and an error-level log line.

Three call sites were unguarded:

Site	Reachable when
EntitlementService::setForEmployee()	HR passes a stale typeId
EntitlementService::bulkSet()	same, via the bulk endpoint
BalanceService::ensureEntitlement()	runs inside the missing-entitlement handler, so the exception it raised was never caught by the try it sits in

The two in EntitlementService did the same find-then-check, so they are now one assertCountingType() helper. resolveType() already handled this correctly; these now match it.

Testing

Full suite: 161 tests, 441 assertions, 0 failures (4 new). Each new test was verified to fail against the unfixed code — the withdrawal one leaving the original at WITHDRAWAL_PENDING instead of CANCELLED, the type ones raising DoesNotExistException instead of ValidationException. php -l clean. No frontend change.

🤖 Generated with Claude Code