Add a negative-control scenario: boots outside the repeat window

[sepehr-safari]

Good First Issue

Add a scenario boot-outside-repeat-window. It is a negative control for the
boundary of REPEATED_BOOT_NOTIFICATION: two boots that are far enough apart must
NOT be reported as a reboot loop.

The rule groups BootNotification calls into a five minute window. #139 covers the
inside of that window, three boots one minute apart. Nothing covers the outside, so
a change that widened the window, or made the comparison inclusive, would pass the
whole suite today.

What to do

1. Create
   packages/toolkit/src/scenarios/__scenarios__/boot-outside-repeat-window.ts
2. Build a synthetic trace with two boots comfortably outside the window:
   • BootNotification at 2026-02-01T11:00:00.000Z, and its CallResult with
     interval: 300
   • Heartbeat at 11:03:00.000Z, and its CallResult
   • BootNotification at 11:06:30.000Z, and its CallResult with
     interval: 300
   • Heartbeat at 11:09:00.000Z, and its CallResult
3. Set expectedFailures: []
4. Add { type: 'no_failures', params: {} } as the assertion
5. Register, update counts, run the checks and add a patch changeset, exactly as
   in the steps above

Why those timestamps

The two boots are 390 seconds apart against a 300 second window, so they are
outside it with real margin rather than sitting on the boundary. The heartbeats
between and after keep the heartbeat rules quiet: each boot renegotiates a 300
second interval, and no gap exceeds twice it. This trace was run against the
detection engine and reports no failures.

Use distinct messageId values for each boot and its matching response.

Files to modify

Same seven as Issue 1, with the new file named
boot-outside-repeat-window.ts.

Guidelines

• Reserves station ID CS-SYNTHETIC-023.
• Everything else as in Issue 1: no failures expected, fix the trace rather than
  expectedFailures, branch off current main, patch changeset.

How to claim

Comment "I'd like to work on this" and it will be assigned to you.

Please hold one open claim at a time. Once the pull request for it is merged, say
which issue you want next and it will be assigned.