feat(scenarios): add repeated-boot-notification scenario

[MayurK-cmd]

Summary

Adds the repeated-boot-notification scenario to the scenario corpus, covering the REPEATED_BOOT_NOTIFICATION detection rule (the one rule that shipped in #114 without an exercising scenario). The synthetic trace on CS-SYNTHETIC-020 reboots a station three times in three minutes (one BootNotification per minute) followed by a single Heartbeat — all three boots land inside the rule's 5 minute window and read as a clear reboot loop rather than a borderline case.

Related Issue

Closes #139

Changes

• New scenario file packages/toolkit/src/scenarios/scenarios/repeated-boot-notification.ts with three BootNotification Calls + matching CallResults, one Heartbeat round, expectedFailures: ['REPEATED_BOOT_NOTIFICATION'], and an event_count assertion (action BootNotification, min 3)
• Registered in packages/toolkit/src/scenarios/index.ts (import, scenario constant, scenarios[], scenarioNames[], named export)
• packages/toolkit/src/scenarios/index.test.ts: count 19 → 20, name order, getScenario case, plus a new engine-integration test confirming REPEATED_BOOT_NOTIFICATION fires
• Scenario count bumped from 19 to 20 in tests/external-fixture/test.mjs, README.md, and packages/toolkit/README.md
• New changeset .changeset/repeated-boot-notification-scenario.md (patch bump for @ocpp-debugkit/toolkit)

Checklist

• Tests added or updated for the behavior this PR introduces
• Lint passes (pnpm lint)
• Typecheck passes (pnpm typecheck)
• Tests pass (pnpm test) — 558/558
• Build passes (pnpm build)
• Changeset added (if changing publishable package behavior)
• CURRENT_STATE.md updated (if applicable)
• AGENTS.md updated (if architecture or build commands changed)
• No secrets or sensitive data in committed artifacts
• Untrusted-input handling reviewed (if touching parsing, CLI, or UI)

Notes for Reviewer

• The trace uses distinct messageId values (msg-boot-1, msg-boot-2, msg-boot-3, msg-hb-1) so the three boots and their matching CallResults are unambiguous to the parser
• Verified locally with ocpp-debugkit scenario run repeated-boot-notification — only REPEATED_BOOT_NOTIFICATION fires (no other rule)
• Verified with ocpp-debugkit ci — 20/20 scenarios pass
• The boot timestamps are exactly 60 s apart and the closing Heartbeat is 60 s after the last boot, so the whole trace spans 3.5 minutes — well inside the 5 minute detection window
• Scenario count was confirmed by running the suite, not assumed

[sepehr-safari]

The scenario itself is right, and I have fixed up the branch around it.

I ran your trace through the engine and it reports REPEATED_BOOT_NOTIFICATION
at warning and nothing else. Three boots a minute apart sit well inside the five
minute window, the trailing heartbeat keeps the heartbeat rules quiet, station
CS-SYNTHETIC-020 is the reserved one, and the changeset is patch. Your scenario
file and changeset went in unchanged.

What needed repairing was the merge, not your work. This branch was cut before #161
landed, and the earlier conflict resolution went wrong in two ways worth knowing
about:

• It deleted packages/toolkit/src/scenarios/__scenarios__/heartbeat-timeout.ts.
  That is your own scenario from feat(scenarios): add heartbeat-timeout scenario for TIMEOUT_NO_HEARTBEAT #161, so merging as-is would have reverted it.
• Three > characters were left behind from the resolution, at index.ts:151 and
  index.test.ts:26 and :256. Those are syntax errors, so typecheck and
  build both failed and index.test.ts would not even parse.

The scenario count had also moved twice while this sat, because #169 landed
meter-value-zero in the meantime. It is 21 now.

I restored the deleted file, dropped the markers, rebuilt the registry wiring on
current main, and set the count to 21 across all four sites. Full check passes:
format:check, lint, typecheck, build, 561 tests, external fixture 56.

For next time, the thing that avoids all of this: instead of resolving conflicts by
hand, git fetch upstream && git merge upstream/main and if the result looks
tangled, git merge --abort and branch fresh off main, then copy your scenario
file across. A scenario touches so few files that starting clean is usually faster
than untangling.

Merging now. That is the sixteenth of sixteen detection rules covered, and it takes
the corpus to 21, past the 20+ mark v1.0 asks for. Thank you, that is a real
milestone and your second merged scenario.

[MayurK-cmd]

Yeah, I was trying to solve the conflicts. Thank you. I will look for more issues; happy to raise a PR!