Add a new scenario: repeated-boot-notification #139

Good First Issue

Add a new scenario repeated-boot-notification. The
REPEATED_BOOT_NOTIFICATION rule shipped in #114 without a scenario, so it is
the one rule in the corpus with no trace exercising it.

What to do

1. Create
   packages/toolkit/src/scenarios/__scenarios__/repeated-boot-notification.ts
2. Build a synthetic trace of a station rebooting in a loop:
   • BootNotification at 2026-01-15T08:00:00.000Z, and its CallResult with
     interval: 300
   • BootNotification at 08:01:00.000Z, and its CallResult
   • BootNotification at 08:02:00.000Z, and its CallResult
   • Heartbeat at 08:03:00.000Z, and its CallResult
3. Set expectedFailures: ['REPEATED_BOOT_NOTIFICATION']
4. Add an assertion, for example
   { type: 'event_count', params: { action: 'BootNotification', min: 3 } }
5. Import and register in packages/toolkit/src/scenarios/index.ts
6. Update the scenario count and name list, see "Files to modify"
7. Add a changeset with pnpm changeset, and pick patch. Scenario additions
   are patch releases, see
   Adding a Scenario.

What makes the rule fire

The rule groups BootNotification calls into a five minute window and reports
when two or more land inside one. Three boots one minute apart sit comfortably
inside that window and read as a genuine reboot loop rather than a borderline
case. Use distinct messageId values for each boot and its matching response.

Files to modify

• packages/toolkit/src/scenarios/__scenarios__/repeated-boot-notification.ts (new)
• packages/toolkit/src/scenarios/index.ts (register, and add to scenarioNames)
• packages/toolkit/src/scenarios/index.test.ts (count, name order, getScenario)
• tests/external-fixture/test.mjs (count)
• README.md (count)
• packages/toolkit/README.md (count)
• .changeset/ (new changeset file)

Guidelines

• All data must be synthetic. This scenario reserves station ID
  CS-SYNTHETIC-020, so please use that one.
• Follow the pattern in an existing scenario file, unresponsive-csms.ts is a
  good short example.
• Verify with ocpp-debugkit scenario run repeated-boot-notification that
  REPEATED_BOOT_NOTIFICATION is the only failure reported. If another rule
  fires, adjust the trace rather than adding the extra code to
  expectedFailures.
• Then run the full local check from
  Verify Locally.
  ocpp-debugkit ci covers neither formatting nor lint nor types, and CI stops at
  the first failure.
• The scenario count depends on what has merged ahead of you. Run the suite and
  use the number it reports rather than assuming.

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. That keeps issues from
sitting claimed while another is still in review, so other newcomers can see
what is genuinely free.