SSR / foldkit-ssr

Costs and limits

SSR.render renders the view twice. That is the view check. A static region's render runs once.
SSR.hydrate relies on how Foldkit hydrates today. It gives Foldkit a config whose init returns the resumed Model, and removes the Flags key, which Foldkit would otherwise require a payload for. The tests pin both, and fail the day Foldkit changes. foldkit#1449 asks whether Foldkit would support this directly.
A resumable page leans on two Foldkit behaviours, each pinned by a test here and by Foldkit's own: the first patch removes attributes the browser's view does not assert, and a control's value is re-asserted to the Model's. It does not depend on Runtime.hydrate rendering its first frame before it returns, which Foldkit does today without promising it: until that frame commits (Render.afterCommit), the page keeps answering from its markers and sends the live page what only it can answer.
Development is not production. Under Vite's dev server, Foldkit's model preservation restores the previous Model after a reload and skips adoption.
A closure handler makes its event wait for boot. SSR.render's result lists each under unnamed ({ element: 'button#point', event: 'pointerdown' }), and on a page that waits to boot SSR.entry and SSR.generate warn about each once per process, naming the fix.