Code generators still emit Zig 0.15 APIs as string literals, so regenerated code will not build

[gHashTag]

Part of #761.

Nine files under src/vibeec/codegen/ and src/phi-engine/ emit Zig source text as string literals. That emitted text still uses 0.15 APIs — std.fs.cwd(), std.time.timestamp(), readAll — so anything regenerated from a .tri spec will not build on 0.16.

Why they were deliberately skipped

Twice during the migration a tree-wide regex rewrote text inside those literals, and both times it had to be reverted:

• Four generators would have emitted @import("tri_io") into standalone generated files that have no such module.
• zig ast-check cannot see inside a string literal, so there was no verification covering the change at all.

An agent reached the same conclusion independently for tests_gen.zig and left its 182 emitted lines alone.

Why this is a different task, not a continuation

Migrating a generator changes its output, and generated files are standalone — they cannot import the shim modules the rest of the tree uses. The emitted code has to be self-contained: construct its own Io, or avoid needing one.

It also needs a verification story the rest of the migration did not: generate, then compile the generated file. Counting sites is meaningless here, because ast-check and fmt are both blind to string contents. A golden-output comparison is the natural gate.

Scope

grep -rl 'writeLine("[^"]*std\.fs\.\|writeLine("[^"]*std\.time\.' src/vibeec/codegen/ src/phi-engine/

returns 9 files. tests_gen.zig alone carries 182 emitted lines.