fix(tests): copy the runner, not /bin/cat, as the POSIX blocked image

[OhOkThisIsFine]

Problem

daemon_runtime_process_fingerprint_never_hashes_replacement_path (POSIX variant) copies /bin/cat to a temp file named image and executes the copy. On Ubuntu 25.10+/26.04 — and any system with uutils/Rust coreutils — /bin/cat is a multi-call binary. A copy invoked under the name image prints coreutils: unknown program 'image' and exits 1, so the test fails at ASSERT(setup).

Reproduced on WSL Ubuntu 26.04 (uutils coreutils 0.8.0):

$ cp /bin/cat "$d/image" && echo hi | "$d/image"
coreutils: unknown program 'image'
exit=1

Fix

Mirror the Windows variant of the same test, which already copies the test runner and parks it in a __cbm_runtime_image_holder argv mode:

• tests/test_main.c — the __cbm_runtime_image_holder mode gains a POSIX branch: block reading stdin until EOF, exactly the behaviour the cat donor provided.
• tests/test_daemon_runtime.c — runtime_test_spawn_blocked_executable passes the holder argument; its target must now be a copy of the runner (it has exactly one caller). The POSIX fixture copies the runner via runtime_test_copy_self_image instead of /bin/cat.
• The /bin/echo replacement donor is gone too. It was only hashed, never executed — and on a uutils system cat and echo can be the same multi-call bytes, which would break the fixture's original != replacement precondition. The replacement is now a small data file, mirroring the Windows variant.

No macOS signing change is needed: the image copy stays byte-identical to the runner, and the identical-copy fixture already proves such a copy executes.

Verification

scripts/test.sh --suites daemon_runtime BUILD_DIR=build/wsl on WSL Ubuntu 26.04 (uutils coreutils 0.8.0): 44 passed / 0 failed, including daemon_runtime_process_fingerprint_never_hashes_replacement_path.

🤖 Generated with Claude Code

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.