[PATCH] Avoid a REPACK worker startup hang

Hi hackers,

On REL_19_STABLE at 6bc236c8, my automated (AI) harness reproduced a
worker startup failure 3/3 times in each of two clusters. Start a
disposable postmaster with a low RLIMIT_NPROC, open the leader connection,
exceed that limit with same-UID helper processes, then run
`repack (concurrently) t`.

The postmaster logs `could not fork background worker process: Resource
temporarily unavailable`. No worker starts, and the leader remains in
IPC/RepackWorkerExport until an external statement_timeout; without one it
has no internal exit. The condition-variable wait consumes the latch wake
reporting the worker-state change.

The attached patch waits directly on the latch, checks the worker handle,
reports an initialization error if it stopped, and preserves queued errors.
The injection test covers failure before DSM attachment and after queue
attachment, unchanged storage, and same-backend retry.

Assertions/injection-points build: 14/14 isolation, 4/4 injection
regression, 240/240 core regression.

I haven't spent much time reviewing this manually: I'm testing several PG19
areas in parallel. The harness tested this thoroughly, but I'd appreciate a
look from people who worked on this. If it doesn't make sense, please let
me know; I'll exclude it from scope.

Attached: 0001-repack-worker-startup.patch

Nik