chore: size scenario changesets as patch, not minor

The changeset from #133 was a minor, so the pending release PR proposed 0.5.0.
That number is reserved for OCPP 2.0.1 in both ROADMAP.md and CURRENT_STATE.md,
and spending it on one new scenario would push the 2.0.1 work to 0.6.0 and break
the milestone-to-version mapping the project has held since v0.1.

Retags the pending changeset to patch, so the release recomputes to 0.4.3.

Adds the convention to the "Adding a Scenario" section, which did not mention
changesets at all. A new scenario does add a public export, but scenarios are
test corpus rather than consumer API surface: nothing is built against an
individual scenario constant, and the registry is consumed as a whole through
scenarios and getScenario(). #133 was asked for a minor during review, and
#137, #138 and #139 are queued behind it.

Closes #142

Author: sepehr-safari

.changeset/warm-dragons-smile.md

@@ -1,5 +1,5 @@
 ---
-"@ocpp-debugkit/toolkit": minor
+"@ocpp-debugkit/toolkit": patch
 ---
 
 feat(scenarios): add firmware update success scenario

CONTRIBUTING.md

@@ -238,6 +238,14 @@ trace with expected failure outcomes and optional assertions.
    check from [Verify Locally](#4-verify-locally). `ocpp-debugkit ci` does not
    cover formatting, lint, or types.
 
+5. Add a changeset with `pnpm changeset`, and pick **patch**. A new scenario does
+   add a public export, but scenarios are test corpus rather than consumer API
+   surface: nothing is built against an individual scenario constant, and the
+   registry is consumed as a whole through `scenarios` and `getScenario()`.
+   Minor and major releases are reserved for changes to the analysis engine, so
+   version numbers keep lining up with the milestones in
+   [ROADMAP.md](ROADMAP.md).
+
 ### Guidelines
 
 - All data must be **synthetic** — no real station IDs, transaction IDs, idTags,