fix(timer): count-to-end events absorb overtime in expected end times

The server computed rundown/group expected end times as
`expectedStart + duration`, ignoring `countToEnd`. For a count-to-end
last event running in overtime this pushed the projected end far past
(or before) its fixed end time, producing nonsensical values (e.g. a
negative expected rundown end) and leaving group/flag readouts stuck on
"due". It also never broke the link chain after a count-to-end event,
unlike the client.

A count-to-end event ends at its fixed end time regardless of preceding
overtime (matching `getExpectedFinish` for the running timer), so its
expected end should pin to the planned end and absorb the accumulated
offset.

- add shared `getExpectedEnd` helper in ontime-utils that pins
  count-to-end events to their planned end
- use it in `getExpectedTimes` for both rundown and group end
- break the `isLinkedToLoaded` chain after a count-to-end event in
  `loadGroupFlagAndEnd`, mirroring the client metadata logic
- delegate the client's `getExpectedTimesFromExtendedEvent` to the shared
  helper to remove the duplicated formula that caused the drift
- add unit and runtime-state tests covering overtime absorption and the
  chain break

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ACGuFWt5aN7Fv3AkYXgxLm

packages/utils/index.ts

@@ -80,7 +80,7 @@ export { validateEndAction, validateTimerType } from './src/validate-events/vali
 
 // feature business logic
 
-export { getExpectedStart } from './src/date-utils/getExpectedStart.js';
+export { getExpectedEnd, getExpectedStart } from './src/date-utils/getExpectedStart.js';
 
 // feature business logic - rundown
 export { checkIsNow } from './src/date-utils/checkIsNow.js';