test: cover dead rebootstrap ground gold gate

Author: MikelCalvo

internal/minimal/shared_world_test.go

@@ -15119,9 +15119,12 @@ func TestSharedWorldRegistryVisibleGroundItemFramesRejectsDeadSubject(t *testing
 	if !registry.RegisterGroundItem(ownerID, "ground-owner-login", owner, 0x0A0B0C31, inventory.ItemInstance{ID: 1031, Vnum: 27001, Count: 1, Slot: 5}) {
 		t.Fatal("expected owner ground item registration to succeed")
 	}
+	if !registry.RegisterGroundGold(ownerID, "ground-owner-login", owner, 0x0A0B0C32, 350) {
+		t.Fatal("expected owner ground gold registration to succeed")
+	}
 
 	if frames := registry.VisibleGroundItemFrames(deadSubject); len(frames) != 0 {
-		t.Fatalf("expected dead subject to receive no visible ground-item rebootstrap frames, got %d", len(frames))
+		t.Fatalf("expected dead subject to receive no visible ground-item or ground-gold rebootstrap frames, got %d", len(frames))
 	}
 }
 

spec/protocol/non-player-reward-bootstrap.md

@@ -120,7 +120,7 @@ The guard checks the current registered owner snapshot, not only the caller-supp
 Ground reward visibility fanout and lookup are also live-recipient guarded: dead visible peers do not receive `ITEM_GROUND_ADD` / `ITEM_OWNERSHIP` on registration, do not receive `ITEM_GROUND_DEL` when the ground entry is later removed, and cannot resolve pending ground handles through the visibility/pickup seam while they remain at the current bootstrap `0`-HP floor.
 Transfer/rebootstrap destination visibility uses the same recipient gate for both item-shaped and gold-shaped entries: moving a zero-HP owner into a map/AOI with existing ground entries queues no destination `ITEM_GROUND_ADD` / `ITEM_OWNERSHIP` burst to that dead recipient, while the ground entry remains available to living visible sessions.
 Ordinary session position updates that rebuild destination visibility use the same zero-HP gate, so a dead recipient cannot reacquire ground-entry visibility by arriving through a movement/sync-style shared-world update path instead of the structured transfer path.
-Fresh same-socket rebootstrap uses the same guard before building the selected character's trailing ground-entry burst, so a still-dead session cannot reacquire `ITEM_GROUND_ADD` / `ITEM_OWNERSHIP` visibility frames for pending ground rewards merely by re-entering the map while still at the bootstrap `0`-HP floor.
+Fresh same-socket rebootstrap uses the same guard before building the selected character's trailing ground-entry burst, so a still-dead session cannot reacquire `ITEM_GROUND_ADD` / `ITEM_OWNERSHIP` visibility frames for pending ground item-shaped or gold-shaped rewards merely by re-entering the map while still at the bootstrap `0`-HP floor.
 Ground pickup also skips party-style delivery back into an owner that has since reached the bootstrap `0` HP floor: the ground handle keeps its owner metadata for display/ownership, but the live owner snapshot is withheld so a living collector either takes the item through the ordinary collector path or fails closed on collector capacity without mutating the dead owner's inventory/gold.
 Ground reward registration re-checks the registered owner snapshot before trusting the caller-supplied character copy, so a stale owner snapshot cannot create item-shaped or gold-shaped reward ground entries after the registered owner has already changed selected-character identity (`id`, `vid`, or name) or moved to a different runtime location.
 Lookup, pickup-resolution, and removal also re-check the registered collector snapshot before trusting the caller-supplied character copy, so a stale collector snapshot cannot see, resolve, or remove item-shaped or gold-shaped reward ground entries after that collector has already reached the bootstrap `0`-HP floor, changed selected-character identity (`id`, `vid`, or name), or moved out of the exact runtime location represented by the supplied pickup attempt.