Pool Lily Pad memory

The earlier 3-2 greeting looked for a completed 31014 event. Source3-1 publishes no event history, and its storage schema rejects that event; the old test bypassed the parser by building an impossible notebook.

The native source31 snapshot now exposes only two already saved facts: Dave granted the free Lily Pad packet, and how many pads were placed from it. Paid packets never enter that registry. The browser creates a separate observation-only journal receipt, removing renderer state, plants and live choice capabilities. Existing binary choice admission is unchanged; the new idle receipt is rejected by the paid-generation request schema.

The free notebook endpoint stores these facts in the current account, campaign and cycle. An explicit empty new-attempt receipt replaces old facts; a live choice without observations cannot erase them. Callback context distinguishes a granted packet from actual planting and cannot establish survival, warning delivery, damage or a new reward. The later greeting now qualifies on an actually planted gift. An empty/unplayed history keeps the normal greeting.

Verification: native source31 entry/save audit first failed on the absent projection, then passed the real paid/free placement distinction and existing full 15-wave/boss/trophy progression. tools-net/pool-memory-chain.mjs feeds that native output through the actual browser projection and journal into the real Hono notebook route and isolated PGlite memory store. Lost-response retries remain idempotent; another account/campaign sees no receipt; no provider is called. Focused schema checks reject invalid counts, fake event history and paid requests from an observation. Full host and web checks are recorded in the game release note.

This does not replay old Lily outcomes for players whose old release never recorded them, and it does not prove a particular Lily survived. No save-format, wave, difficulty, pricing or production settings changes.