[Bug]: Publishing one row blanks the holes on every other page until the next full publish

Summary

Publishing a single data row (e.g. a post) makes the server islands (<instatic-hole>) on every other published page render empty until the next full site publish.

publishDataRow bakes its own artefact at getPublishVersion() + 1 and then calls bumpPublishVersion(). The other pages' baked HTML keeps the data-instatic-version the last full publish stamped into their placeholders. handleHoleRequest answers any v other than the current version with <instatic-hole-stale data-instatic-stale="true"></instatic-hole-stale>, and the hole runtime swaps whatever it receives into the page (el.outerHTML = html). So the request-dependent content disappears for visitors on every page except the one row that was published.

By the code, the same applies to every path that bumps the version without re-baking shells: the scheduled row publish, a plugin's content publish, and deleting a published row.

Steps to reproduce

1. Fresh SQLite install. Add a page with slug index whose Text module reads Hello {route.query.q} (request-dependent, so it bakes as a hole — note {route.path} is fixed per route and bakes inline), plus a posts entry template and one post.
2. Full publish (publishDraftSite, or Publish in the editor).
3. The baked published/<slot>/index.html carries data-instatic-version="1"; GET /_instatic/hole/<nodeId>?v=1&u=%2F%3Fq%3Dworld returns <p>Hello world</p>.
4. Publish only the post (POST /admin/api/cms/data/rows/<id>/publish, or publishDataRow).
5. index.html still carries data-instatic-version="1"; the same request now returns the stale sentinel.

Script output (in-process on SQLite, against the commit below):

after full publish   — baked version 1 → fragment: <p>Hello world</p>
after one row publish — baked index.html version still 1 → fragment: <instatic-hole-stale data-instatic-stale="true"></instatic-hole-stale>

Expected behavior

Publishing one row leaves every other page's holes working.

Actual behavior

Every other page's holes are refused as stale and render empty until someone runs a full publish.

Possible fixes

• Have a row publish re-stamp (or re-bake) the other pages' hole shells, or
• key hole staleness on the node's published snapshot rather than the site-wide version, so a bump that did not touch a node's page does not invalidate it, or
• have the hole runtime treat the stale sentinel as "reload once" instead of swapping it in.

Version or commit

39760355 (main, "refactor(branches): one adapter per entity kind (#528)")

Deployment mode

Local dev with Bun