Design: persistence for TS cores without eject (SQL in-process or file KV?)

[carvalab]

Many real apps need persistence beyond a flat blob, because the logic is relational: entities reference each other, queries aggregate, and writes touch several tables at once. A whole-model file with writeFile/readFile can carry that, but then the app owns a serialization format and every query as a hand-written scan. I've been mapping what the TS core path actually offers, and I want to check the intended direction.

What I found so far:

• Cmd.persist() compiles but no host implements it yet (NS1028); the ts-core skill points at Cmd.writeFile/Cmd.readFile as the persistence pattern.
• Cmd.request/Cmd.host with a custom name comes back rejected in the default wiring, because the generated TS wiring binds no host services. I confirmed in ts_core_main.zig and effects.zig that unbound host calls get an err: "rejected" result.
• That leaves, as I see it: a whole-model file KV with a hand-rolled format, spawning a system sqlite3 CLI per query, or ejecting to bind a Zig host service with SQLite linked in-process. npm-based bindings (libsql etc.) are ruled out by the subset.

Questions:

1. Is in-process storage for TS cores on the roadmap (a builtin KV or SQL host service), or is the file KV pattern the intended answer for now?
2. If the file KV pattern is it: any guidance on the 1 MiB per-file ceiling? And is NATIVE_SDK_APP_DATA_DIR supposed to be set by the runner? The voice-memo example reads it through envMsgs, but I couldn't find anywhere in the CLI that injects it, so I'm deriving the data dir from HOME/XDG myself.
3. I'd rather not spawn a subprocess per query, partly for latency and partly because it pins the app to whatever sqlite version the user has. Is that pattern something you'd discourage?

I think relational data is common enough that the answer shouldn't be "eject and write Zig." Curious what you'd recommend.