Published FrankenTerm Linux asset contains only ft; current guide requires a signed process family

The latest published FrankenTerm Linux asset contains a working ft CLI, but current installation docs require a coherent CLI/mux/PTY-guardian family with checksum, minisign signature, and a current installation receipt. Please publish that documented Linux family as a release asset and make the ACFS module select it.

This is a release/documentation integration gap. The CLI checks below do not establish the complete process-family contract; I have not executed the newer main-branch installer or claimed that its full installation fails.

Verified on 2026-10-25 without reading ACFS or FrankenTerm source:

• Latest published release: v0.15.1, published 2026-08-21.
• ft-linux-amd64.tar.xz is 19,789,208 bytes. Its SHA256 is f063460275836799fa887a2765616c87109b410b9ebef1febbfee106376de12f, matching the per-asset checksum, SHA256SUMS, and release manifest.
• The archive contains one regular ft executable. It is Linux x86-64 ELF; its highest GLIBC version requirement shown by readelf is GLIBC_2.39. It runs on our x86-64/glibc 2.43 host.
• Installing only that member succeeds. ft --version reports ft 0.15.1 (ced654de8b1772793a8966e7c3bf67dcd0dd39e8); ft --help and normal PATH resolution both exit 0. No watcher or model ran.
• The manifest marks this artifact unsigned; same-origin checksums establish package integrity, not an independent signature.

The black-box installer plan remains:

bash ~/.acfs/install.sh --yes --mode vibe --skip-ubuntu-upgrade \
  --skip-preflight --only stack.wezterm_automata --print-plan

It selects base.system, users.ubuntu, lang.rust, and acfs_generated_install_stack_wezterm_automata(). The plan does not expose the Cargo package or resulting binary name. It was only printed, not executed.

Our older installation task records a wa/frankenterm naming mismatch. I have not reproduced that error against today's installer, so this is an open naming check rather than a confirmed current defect. The separate, recorded 2026-10-03 source-build failure is definite: two uncapped parallel rustc processes reached 8.1 GB and 5.5 GB RSS and exhausted the host. We did not repeat it today: both available hosts failed our 16 GB available-memory precheck. The release asset avoids needing any Cargo build.

Duplicate checks found no exact release-first/naming report. Closed #371 covers CARGO_TARGET_DIR copying, which is a different failure. Requested result: the release and ACFS installation should supply the coherent family required by the current guide. The older standalone CLI asset should be identified as a narrower capability, with source builds kept memory-bounded.