docs(runicnpc): 9e step 2 — the Carbon Kits reload, found and fixed (D329)

A real Carbon first boot does not meet it: the automatic Kits reload took. The
session's failure was a second load of RunicNPC inside the one second before
its Kits reload timer fired, which died with it; Oxide never shows it because
loading RunicNPC reloads Kits there too. D329 (the org lead's choice): the
reload is owed in state.json until Kits has the example kits, three tries at
most. API.md describes the two new state fields. Code: runicnpc-rust#17.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

runicnpc/API.md

@@ -407,6 +407,11 @@ route is walked back and forth. An NPC joins the route at its nearest point.
   (D324). On a server no site manages it also adds the four example profiles (`raider`, `campguard`, `sniper`,
   `juggernaut`). Then it reloads Kits, which reloads RunicNPC with it. **Nothing is written again, even if you
   delete them** (D280, D284, D289).
+  The kits written are then **owed a Kits reload** (`kitsReloadOwed`, `kitsReloadTries`; D329) until Kits knows
+  them all. Every load, and Kits coming back, settles the debt: it is cleared once Kits has the kits, and otherwise
+  the reload is asked for again. So a load interrupted inside that one second still ends with working examples. After
+  three reloads RunicNPC stops asking and warns with the command to run (`c.reload Kits` / `oxide.reload Kits`).
+  A `state.json` from before D329 has neither field and owes nothing.
 - **A Kits reload reloads RunicNPC** on both frameworks, because RunicNPC requires Kits, and the NPCs it had spawned
   are lost: placements come back, an event's NPCs do not. **Do not reload Kits while an event runs** (D283).
 - `config/RunicNPC.json`: