compile_smoke msys: ci/include tebako_fs_fstat stub mismatches real header (3.4 prism_compile.c); msys smoke never compiles _WIN32 code

[ronaldtse]

ci/include stub gap: tebako_fs_fstat signature mismatches the real libtfs header (3.4 prism_compile.c, real-mingw compile only)

Found while gating #108 with a REAL cross compile (CC=x86_64-w64-mingw32-gcc 16.1.0, tools/compile_smoke 3.4.9 --platform msys):

prism_compile.c:44:29: error: passing argument 2 of 'tebako_fs_fstat' from incompatible pointer type [-Wincompatible-pointer-types]

• Reproduces on main identically — pre-existing, unrelated to patches: msys spawn carrier to parity — spec 30 plan machinery on windows #108.
• Invisible to CI: the msys compile smoke runs with the default native gcc (_WIN32 undefined), so the windows half of any patch — including this call site in 3.4's prism_compile.c patch path — is never compiled. The struct that needs fixing is either the vendored stub declaration in ci/include (which "declares exactly the c_api surface the patches use") or the patch's call — whichever drifted from the real libtfs tebako_fs_fstat.
• The 3.4-line windows runtime builds are green in the factory (they compile against the real libtfs headers), so this is a compile-smoke fidelity gap, not a product bug.

Two follow-ups:

1. Fix the stub (or the call site) so 3.4.x --platform msys compiles all patched TUs under a real mingw gcc.
2. Consider letting tools/compile_smoke --platform msys prefer x86_64-w64-mingw32-gcc when available (fall back to native): the native-gcc msys smoke structurally cannot compile _WIN32 code, which is exactly where the spawn/argv bridging lives — the ruby#107 drift shipped through that hole.