feat(scenarios): add heartbeat-timeout scenario for TIMEOUT_NO_HEARTBEAT

[MayurK-cmd]

Summary

Add a heartbeat-timeout scenario covering the TIMEOUT_NO_HEARTBEAT detection rule, which previously had zero scenario coverage. The synthetic trace boots a station with interval=300, then sends a StatusNotification past the 2× interval threshold with no Heartbeat anywhere in the trace.

Related Issue

Closes #137

Changes

• New packages/toolkit/src/scenarios/__scenarios__/heartbeat-timeout.ts — synthetic trace with BootNotification, StatusNotification at 06:12:00.000Z, and no Heartbeat
• Registered in packages/toolkit/src/scenarios/index.ts — import, registry, scenarioNames, exports
• Updated packages/toolkit/src/scenarios/index.test.ts — count, name list, getScenario, engine integration test
• Updated tests/external-fixture/test.mjs — scenario count 18→19
• Updated README.md and packages/toolkit/README.md — scenario count 18→19
• Added .changeset/heartbeat-timeout-scenario.md — minor 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)
• 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 scenario uses the reserved station ID CS-SYNTHETIC-018. Verified via ocpp-debugkit scenario run heartbeat-timeout that TIMEOUT_NO_HEARTBEAT is the only failure reported — no other detection rules fire on this trace.

[sepehr-safari]

Thanks for this, and welcome. The trace is right, the shape follows
unresponsive-csms closely, and the reviewer note is accurate: I ran it and
TIMEOUT_NO_HEARTBEAT is the only rule that fires, at warning, once.

I ran the full local check on your head commit, in CI order: format:check,
lint, typecheck, build, then the suite at 555 passing, the external fixture
test at 56, and ocpp-debugkit ci at 19 of 19. All green, and CI now agrees. You
also picked up the missing getScenario('refused-authorization') assertion in
index.test.ts, which was a genuine gap left behind by #159. That one was not
asked for and it is correct, so please keep it in.

Two changes and it can go in.

1. The changeset should be patch, not minor. This one is on me. Step 7 of
#137 says "minor bump", and that wording is stale: #143 moved scenario additions
to patch and I never backported the change into the three scenario issues I had
already opened. You followed the issue exactly. The reasoning for patch is in
Adding a Scenario:
a scenario adds a public export, but the corpus is test material rather than
consumer API surface, and minor releases are reserved for engine changes so the
version numbers keep lining up with ROADMAP milestones. One line in
.changeset/heartbeat-timeout-scenario.md:

'@ocpp-debugkit/toolkit': patch

I have fixed the wording in #137 and #139 so the next person does not hit it.

2. connector should be connectorId in the StatusNotification payload.
In heartbeat-timeout.ts, the msg-002 payload reads:

{ connector: 1, status: 'Available', errorCode: 'NoError' }

OCPP 1.6 section 4.9 names that field connectorId, and the other eighteen
scenarios all use it. It does not change what this scenario detects, because
TIMEOUT_NO_HEARTBEAT never reads the connector and there is only one
StatusNotification in the trace. It matters because of what the corpus is used
for: detectFailures buckets status history by payload.connectorId and files
anything without that field under unknown, so a trace with connector quietly
takes a different path through the status rules than a real station's traffic
would. The corpus is also what the Studio contract harness and the shared trace
fixtures are generated from, so it is the wrong place to carry a field name that
no station sends.

Nothing else. Once those two are pushed I will run the checks again and merge.

One process note, not a change request: your first CI run sat waiting rather than
failing. GitHub holds workflow runs from first-time contributors until a
maintainer approves them, so that was pending on me, not on you. It is approved
and both jobs pass. Later pushes on this branch run without the wait.

[sepehr-safari]

Sorry for the wait on this, and thank you for the clean turnaround.

Both changes are in and correct: the changeset reads patch, and the payload now
uses connectorId. I pulled your head commit and ran the full check in CI order.
format:check, lint, typecheck and build all pass, the suite is at 555
passing across 20 files, and the external fixture test is at 56 of 56.

The stall was mine and it was my mistake, not a problem with your push. I told you
in the last review that later pushes on this branch would run without waiting for
approval. That was wrong. GitHub keeps the approval gate on every run from a
FIRST_TIME_CONTRIBUTOR, and that status only clears once a pull request of yours
has actually merged, which for you happens with this one. So your push on the 4th
opened a run that sat in action_required for three days waiting on me, showing
you nothing. I have approved it, and I am sorry you were left staring at silence.

Merging once the run is green.