v1.10.0 — carry the wiped page on its history entry

A wipe's entry in knag_history now carries the page it wiped.

Added

• snapshot on a wipe's sealing entry (#252). The removed lines were always recoverable from the following entry's disappeared — 1.9.4 made the description say so — but that reconstruction has a blind spot the code has always documented: a line diff is a set difference, so a page holding the same line twice and losing one of them reports nothing. For a page kept as the only record of something, a reconstruction with a known gap is not the same as the bytes.

  The sealing entry's body already is the pre-wipe page — that is why its own diff is empty by construction — so this exposes what was there rather than storing anything new. No migration, no extra query.

• snapshot_truncated, and a 16 KiB cap. A document may legally be a megabyte, and a week of daily wipes would put seven of those in one response. 🔴 The cut is at a line boundary, never mid-line: nothing is normalized in this product, so a snapshot is worth having because its lines are the bytes that were there, and a byte slice would hand back a final line that was never on the page and is indistinguishable from one that was.

Changed

• loadHistory takes snapshots and only knag_history passes it. The history pane never reads a snapshot and the phone fetches that payload on every open, so the browser's response is the shape it always was. An opt-in argument rather than a second code path: one implementation behind both surfaces is what the MCP/HTTP parity test exists to keep.

• The tool description names the new field, for the reason 1.9.4 exists — a field nothing points at is a field an agent concludes is missing. spec §5 and §14.6 updated: §14.6 had said the MCP shape was identical to GET /api/history, and it is not any more.

Note: a connector re-reads tool descriptions and schemas on reconnect, so this reaches claude.ai at the next handshake rather than at deploy.

Full changelog: v1.9.5...v1.10.0