Item-guid minting can escape the owner's packed block — the namespace invariant transfer.rs relies on is unenforced #71

items/tables.rs:270: item_guid_for packs (owner_guid & 0x00FF_FFFF) << 8 | slot — each owner gets a 256-value block, and slots already consume up to 191 of it. next_item_guid mints max(owner's guids) + 1, so a character whose highest guid drifts past the block boundary starts minting guids inside the NEXT owner's block; separately, two owners whose guids differ only above bit 24 share a block outright. Collision = primary-key insert panic in store_item.

transfer.rs:1454 and transfer.rs:5306 justify preserving item guids across shard transfer because "item rows are guid-namespaced to the OWNER" — the invariant is load-bearing but unenforced.

Fix: restructure the packing so the invariant holds by construction — e.g. owner(24 bits) | per-owner serial(24 bits) with a persisted counter or explicit saturation error — and delete the fallback_slot parameter (the empty-inventory fallback is its only reason to exist). Existing live rows use the old packing, so this needs a migration plan first; design before implementing (hence no agent-safe).

Found by the 2026-08-06 whole-module audit.

Migrated 2026-08-11 from the private tracker (spacetime-core#364).