fix(events): the atlas import, and a teardown that was a no-op (Phase 16a)

Two defects the acceptance walk found in shipped code, both invisible to the
suites that were green on either side of them.

**The spawn atlas cannot import on a stock ServUO tree.** `spawnAtlasSource.js`
dedupes decoration types with a case-SENSITIVE `Map`, but `shard_decor_types.type`
is a PRIMARY KEY under MariaDB's default `..._ai_ci` collation, which folds case.
Stock 57.4's own `Data/Decoration/` names four types under two spellings each
(CheckerBoard/Checkerboard, ChessBoard/Chessboard, MetalChest/Metalchest,
SpinningWheelEastAddon/SpinningwheelEastAddon), and in every pair exactly one is a
real class. The second row raised `1062 Duplicate entry` and took the WHOLE import
transaction down. The blast radius is not decoration: with no atlas, EVERY option
source answers empty and no Phase 12 world verb can be authored at all.

The shard end already knew — `BridgeWorld.cs` resolves a decor type with
`FindTypeByName(name, ignoreCase: true)` and its comment says the atlas and the
decoration files disagree about casing. Folding here is the two ends agreeing.

**Teardown of every world verb was a no-op that reported success.** `revertOwned`
forwarded core's `idempotencyKey` as the despawn's OWN key — and core's key is the
step's, the one `placeOwned` spawned under. `BridgeIdempotency` keys on the key
alone, so the despawn was taken for a repeat and answered with the SPAWN's stored
reply; `OnDespawn` never ran. Core read `ok` with no `refused` and marked every
row `reverted` while the shard still held every object.

Measured on the rig: ledger `world | reverted | 21`, shard `world.owned` 21 alive
with `pruned: 0`, and the identical despawn re-sent with a fresh key removed all
21. It affected all five world verbs, so an invasion's creatures, boss, oracle,
gate and decoration stayed in the world for ever while the console reported a
clean teardown.

`MODULE_API.md` says what that key is for and it is not this: it identifies a
dispatch core never learned the outcome of, so the module can ask about it. No key
is needed on a despawn — a repeat answers `gone`, which both ends already treat as
success — and dropping it also makes the documented empty-`resources` case work,
since no serials means "everything this run owns". The parameter is removed from
`despawnWorld`'s signature rather than left optional.

Both fixes are verified end to end against a real ServUO + sidecar + website rig:
the import now yields 309 decor types (was failing at 313 with 4 collisions),
6,455 spawn points, 800 creatures, 558 landmarks; and a full four-phase run's
teardown left the shard owning 0 objects.

Each new test was confirmed to FAIL without its fix.

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

server/config/uoEventActions.js

@@ -481,12 +481,29 @@ async function placeOwned({ runId, idempotencyKey, what, body }) {
  * shard denies this run ever owned that serial — nothing will ever delete it
  * through this path, so the row must land unresolved with a reason rather than
  * be quietly marked reverted.
+ *
+ * **The despawn carries NO idempotency key, and that is the whole point.** This
+ * function used to forward core's `idempotencyKey` as the despawn's own — which
+ * is the step's key, the very key `placeOwned` spawned under. The shard's
+ * at-most-once store is keyed on the key ALONE (`BridgeIdempotency.Intercept`
+ * does `_byKey.TryGetValue(key, …)`, not a lookup by key AND command), so the
+ * despawn was recognised as a repeat and answered with the SPAWN's stored reply.
+ * `OnDespawn` never ran, core saw `ok` with no `refused`, and every row was
+ * marked `reverted` while the shard still held every object. Teardown of all
+ * five world verbs was a no-op that reported success.
+ *
+ * No key is needed here. A repeat despawn is already safe by the handler's own
+ * three-answer design: the second pass finds the serial gone and answers `gone`,
+ * which is a success on both ends. `MODULE_API.md` says what core's key is FOR,
+ * and it is not this — it identifies a dispatch core never learned the outcome
+ * of, so the module can ask about it. That case arrives here as an EMPTY
+ * `resources` list, and it is answered correctly by the same call: no serials
+ * means "everything this run owns", which is exactly the right sweep.
  */
-async function revertOwned({ runId, resources, idempotencyKey }) {
+async function revertOwned({ runId, resources }) {
   const result = await uoLinkClient.despawnWorld({
     runId: String(runId),
     serials: resources.map((resource) => resource.ref),
-    idempotencyKey,
   })
   if (!result.ok) return { ok: false, error: sidecarReason(result, 'despawn') }