sessions_enabled was read only by the TUI. With it off the TUI hid the
drawer and stopped saving, but the seven session MCP tools stayed on the
wire and still wrote session files, the HTTP routes still created and
appended, and lilbee sessions still worked, so "turning sessions off
writes nothing to disk" held on one surface out of four.

Gate the MCP tools with _tool_if(sessions_enabled()) and refuse inside
each body, matching memory exactly: the decorator keeps them off the wire
when sessions are off at import, and the body check covers the flag being
toggled at runtime. On HTTP and CLI the check lives in the _store()
helper every handler and command already routes through, so the
invariant is structural rather than eight or four call sites that can
drift, which is how this was missed the first time.

The schema budget test measured whatever the environment happened to
register. wiki_ depends on cfg.wiki, memory_ on cfg.memory_enabled, and
crawl on whether the crawl4ai extra is installed, so the same commit read
9672 bytes in the docs-site job and 10143 on a developer box. That is why
a schema regression passed every release job and took down the website
deploy instead. Exclude the ambient families, pin the default surface by
name so an ungated tool fails by name rather than as a byte overflow, and
measure only that. Pinned, the default surface including all seven
session tools is 8799 bytes, under the original 8800 cap, so sessions
never actually breached the budget. The ceiling moves to 9500 to replace
one byte of headroom with room for a tool or two.