perf(ci): let the readiness suites skip a wait none of them are about

[fujibee]

Existing-user impact: NO. CI budget only — but it does touch production code,
so the honest form is: it touches scripts/remote.sh, and the shipped default is
unchanged, with a control that fails if it moves.

The bats (macos-latest 1/4) shard finishes in 24.1 minutes against a
25-minute job cap. Every other shard has 10–17 minutes spare. The most recent
green run on that shard cleared the cap by 54 seconds — so the next test
anyone adds there turns their PR red, for a reason that is not their test.

Where the time goes

Measured from the gaps between consecutive ok lines, on a run that was
cancelled for exceeding the cap:

158s	reaps a ready-timeout child before releasing ownership
151s	the registry lock is free while readiness is still polled (#817)
147s	the command the refusal prints is the command that works (#730)
144s	says a live engine was left behind when it cannot be reaped (#731)
143s	a writable run dir still starts an engine (#730)

12m24s in five cases. Sixth place was 18 seconds.

All five wait out sync start's readiness poll at the shipped 1600 turns. None
of them is about the length of that wait — each needs a state where readiness
never arrives, and forty turns produces that state just as well.

The change

_remote_sync_ready_turns lifts the number out of the loop so it can be asked
for instead of run, and AGMSG_TEST_SYNC_READY_TURNS lets a suite name a
shorter ceiling.

The shipped default is unchanged at 1600, pinned in its own file
independently of every suite that sets the seam — so lowering it reddens
something even if all those suites pass. That file also pins the fallback: a
value that is not a count resolves to shipped, not zero. A ceiling of zero
would end the poll before it began, and the suites would stay green while
measuring nothing.

Per case: what changed, and what did not

case	ceiling	the assertion it still makes
the command the refusal prints (#730)	40	the printed remedy runs — both invocations, the second inside bash -c
a writable run dir still starts an engine (#730)	40	an engine appears
the registry lock is free while readiness is still polled (#817)	40	needs the starter alive across a 3s window; it lives ~2s, and passed 5 of 5 runs
a timed-out starter does not clear another engine's records (#817)	40	the other engine's records survive
a cleanup that cannot retake the lock says so and keeps the record (#817)	40	the message, and both records
says a live engine was left behind when it cannot be reaped (#731)	40	the text, and that the child is still running
reaps a ready-timeout child before releasing ownership	40	the child is reaped

No assertion is touched. The entire test diff is those invocation lines and
nothing else.

What I got wrong first

The first pass seamed only the five cases CI named, and left three slow ones
behind — one of them a case I had already seamed, whose second invocation
goes through bash -c and did not match my pattern. Enumerating from CI's top
five lost by one; deriving from every test that reaches the poll found them.

Measured after: 242s → 25s and 145s → 44s, with 9/9 and 31/31
unchanged, plus 4/4 on the new contract file.

Refs #831