Add a new scenario: firmware-update-failure

[sepehr-safari]

Good First Issue

Add a new scenario firmware-update-failure. The FIRMWARE_UPDATE_FAILURE
detection rule has no scenario covering it. #133 adds the successful firmware
path, so this is the failing counterpart.

What to do

1. Create packages/toolkit/src/scenarios/__scenarios__/firmware-update-failure.ts
2. Build a synthetic trace of a firmware update that fails to install:
   • BootNotification at 2026-01-15T07:00:00.000Z, and its CallResult with
     interval: 300
   • FirmwareStatusNotification with { status: 'Downloading' } at
     07:00:30.000Z, and its CallResult
   • FirmwareStatusNotification with { status: 'InstallFailed' } at
     07:01:00.000Z, and its CallResult
   • Heartbeat at 07:02:00.000Z, and its CallResult
3. Set expectedFailures: ['FIRMWARE_UPDATE_FAILURE']
4. Add an assertion, for example
   { type: 'failure_count', params: { code: 'FIRMWARE_UPDATE_FAILURE', min: 1 } }
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, minor bump for @ocpp-debugkit/toolkit

Which statuses count as a failure

The rule treats exactly four FirmwareStatusNotification statuses as failures:
DownloadFailed, DownloadPaused, InstallFailed, InstallRebootingFailed.
Downloading, Downloaded, Installing and Installed are all clean. The
scenario needs one of the four, and InstallFailed is the most representative.

Keep the whole trace inside five minutes of the boot. Past that, the heartbeat
rule starts looking for a Heartbeat and you would trip a second, unrelated
failure.

Files to modify

• packages/toolkit/src/scenarios/__scenarios__/firmware-update-failure.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-019, so please use that one.
• Follow the pattern in an existing scenario file, diagnostics-failure.ts is
  the closest match since it covers the equivalent rule for diagnostics.
• Verify with ocpp-debugkit scenario run firmware-update-failure that
  FIRMWARE_UPDATE_FAILURE 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.