#9427 fix(files): cap how long a room delivery waits for its refetches

Summary

• The room coalescing from #9419 awaits each delivery's refetches before the next delivery, but a fetch has no timeout of its own: one that hung held the room's deliveries forever, so the tab stopped picking up remote file changes
• Each delivery now waits at most DELIVERY_SETTLE_CAP_MS (60s, above the slowest list read) via the existing withinDeadline helper, which clears its timer; past it, the next delivery's invalidateQueries (cancelRefetch: true) cancels and restarts the hung fetch, the recovery every broadcast gave before coalescing
• Normal deliveries are unchanged: a refetch that settles within the cap is still waited for, never overlapped; a hung first load (no cached data) is joined rather than restarted, as before

Type of Change

• Bug fix

Testing

• New test: a refetch that never settles no longer blocks the next delivery; fails on the pre-fix hook ("expected 2 times, got 1"), passes after; the existing coalescing tests still pass (6/6)
• bun run lint, bun run check:audits (61), bun run type-check

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)