perf: compress embedded espeak-ng-data with rust-embed

[pszymkowiak]

Summary

Follow-up to #60. The embedded espeak-ng-data directory was shipped uncompressed via include_dir!, inflating the release binary from ~27 MB (pre-fix) to ~50 MB. The bytes are mostly phoneme dictionaries — plain text and small binary tables that compress well.

Swap include_dir = "0.7" for rust-embed = { version = "8", features = ["compression", "interpolate-folder-path"] }. Files are DEFLATE-compressed at build time and decompressed when extracted (once, on first piper call). Expected sizes:

	Before #60	After #60 (include_dir)	This PR (rust-embed + deflate)
Linux release binary	~27 MB	50 MB	~32 MB (estimate)
Linux release tarball	~12 MB	22 MB	~13 MB (estimate)

Same staging path ($OUT_DIR/espeak-ng-data populated by build.rs), same first-run extraction to ~/.config/vox/piper/espeak-ng-data/, same PIPER_ESPEAKNG_DATA_DIRECTORY env-var dance. No user-facing change.

Test plan

• CI green on Linux CPU + macOS Metal (the platforms that passed for fix: bundle espeak-ng-data inside binary (fixes #59) #60/fix: align backend preference validation with runtime registry #61)
• Local: download Linux release binary built from this branch, run vox -b piper "hello" on a fresh ~/.config/vox, confirm extraction + audio works
• Compare binary/tarball sizes vs v0.14.0

[pszymkowiak]

Closing — rust-embed v8's compression feature requires a path relative to CARGO_MANIFEST_DIR, which rules out our $OUT_DIR-staged espeak-ng-data. The clean alternative (manual tar+gzip in build.rs + decompress at runtime) doubles the moving parts of the embed for a ~20 MB binary gain.

Per the analysis in #59, a 50 MB Rust ML CLI binary is within the 2026 norm (ruff ~30 MB, bun ~60 MB, deno ~85 MB) and the curl-install UX is unaffected. Keeping the simpler include_dir setup from #60 and revisiting only if binary size becomes a concrete pain point.