Stop the sync engine inheriting descriptors it never uses

[fujibee]

Shards have been reporting every test ok and then sitting silent until the job's 25-minute cap. Three explanations were tried and each was refuted by observation. This one was not guessed — it was photographed.

What was holding the job open

From #566's diagnostics, taken while a macOS shard was hung, after 262/262 ok:

pid 5798   node .../scripts/internal/remote-sync.mjs          (ppid 1)
           fd 144  PIPE 0xc9aea28a590ca110  (65536)

pid 62112  bats --print-output-on-failure tests/test_remote.bats ...
           fd 144  PIPE 0xc9aea28a590ca110
pid 62135  bats ...
           fd 144  PIPE 0xc9aea28a590ca110
pid 62136  bats-format-cat
           fd 144  PIPE 0xc9aea28a590ca110

A surviving sync engine holding the same pipe as bats, at the same descriptor. bats had not exited — all three of its processes were alive, waiting for an EOF that could not arrive while the engine held the write end.

Two things follow, and they explain the two fixes that did not work:

• ppid 1. The engine had already been reparented, so no teardown reaching for a pidfile could have caught it. That is why #559's teardown fix did not stop this.
• fd 144. Not 3, not 4. The engine's spawn site already closed 3 and 4 by name. A descriptor whose number the harness picks cannot be closed by naming it, which is why yesterday's uniform 3>&- 4>&- rule did not stop this either.

The change

Close everything above stderr at the engine's own entry, by range rather than by name, enumerated from /dev/fd where it exists and swept otherwise. It lives at the entry, not at the spawn sites, so it covers every way the engine is started rather than each one separately.

The engine speaks only over stdin, stdout and stderr, and the spawn sites already point those at a log.

The closes are attached to the exec rather than performed before it:

eval "exec$_fd_closes \"\$NODE_BIN\" \"\$SCRIPT_DIR/internal/remote-sync.mjs\" \"\$@\""

One descriptor above stderr belongs to the shell — bash holds the script it is reading at 255, and an enumeration cannot tell that one from a descriptor bats left open. Closing it from a statement would leave the shell reading the rest of its own script through a descriptor it had just given up. As a redirection on the exec the question does not arise: the redirections are applied and the execve follows, with no statement of this script in between.

Bash does defend against the statement form, as it turns out. Given exec 255>&- it moves the script to another number — observed as 11 under both 3.2.57 (macOS /bin/bash) and 5.3.15 — and a script padded to 291 KB, far past any read buffer, still ran to its last line under both. The hazard was right in shape and did not bite. Attaching the closes to the exec retires it rather than resting on that defence.

That is also why no test is added for it. A regression exercising a long script passes against the statement form too, so it could only ever be green; the measurement above is the evidence instead.

This supersedes the norm added in #565. That change made 3>&- 4>&- uniform across scripts/ and enforced it with a test; the norm was right in shape and too narrow in reach. The history is recorded in the commit body so it lives in one place.

Tests

Two, and each fails for a different mistake:

mutation	test 1 (no inherited fds)	test 2 (streams work)
remove the close	fails	passes
let the range reach 0/1/2	passes	fails

Test 2 asserts by using the streams — a marker on stdout, one on stderr, a line through stdin — rather than listing them. A closed 0/1/2 is immediately reissued to whatever opens next, so a listing shows all three either way. An earlier draft asserted exactly that and passed while the code closed all three; that draft is why the mutation table above exists.

Locally: the descriptors reaching the engine are 0 1 2 with this change and 0 1 144 2 3 4 77 without it.

What this does not establish

That it ends the hangs. The mechanism is captured and the fix demonstrably closes it, but whether these shards stop hanging is three consecutive clean runs of the affected shard, not this description.

Unrelated, found on the way

connect: a keyed team fails closed when the remote disallows age-v1 in test_remote.bats fails on integration/remote itself, with or without this change — but only where age is installed. CI skips it (# skip age/age-keygen not installed), so CI has never run it. Reported separately; not touched here.