v0.9.61

Fixed

--runtime fly runs no longer die with a bogus "git user.email is not configured".

The git identity was seeded correctly and readable the whole time — the return code was lying.

SIGCHLD set to SIG_IGN makes the kernel auto-reap exiting children, so their exit status is gone before anyone can read it. asyncio's PidfdChildWatcher then waitpids a pid that no longer exists, catches ChildProcessError, and invents returncode 255 with empty stdout (it can also surface as a raised ProcessLookupError). The disposition is inherited across exec, so a parent leerie does not control — an SSH daemon, a login shell, the Fly launch wrapper — can hand it down.

Only the first subprocess is corrupted, which makes the symptom maximally misleading: whichever check runs first reports a bogus failure and every later one succeeds, so blame lands on that check's subject rather than on the machinery. preflight()'s git config user.email merely had the bad luck of being first, and its rc != 0 or not stdout test dutifully blamed git.

Reproduced in the container image (Python 3.13.5): under SIG_IGN a sh -c "exit 7" reports rc=255; with the reset it reports rc=7.

• _restore_sigchld_default() — called first in main(), before anything spawns.
• preflight() distinguishes "cannot read the child's exit status" (rc=255 + empty stdout; git exits 1, never 255, for an unset key) from a genuinely unset identity, so the operator is no longer sent to fix a git config that is already correct.
• _sigchld_is_ignored() gates preflight() on the kernel's SigIgn mask from /proc/self/status — signal.getsignal() does not reliably reflect an inherited disposition.

DESIGN §6 gains the mechanism alongside the existing returncode-255 discussion: pidfds are immune to waitpid(-1) theft, but not to kernel auto-reaping. Regression test is @linux_only (pidfd + /proc).

Full changelog: v0.9.60...v0.9.61