Survive the shared-memory arena running out of space, and report workers killed by a signal - #6313

POSIX shm is a tmpfs file, so the ftruncate() to ARENA_SIZE_LIMIT succeeded
however little room that filesystem had - the file is sparse, and the shortfall
only surfaced when a process first touched a page tmpfs could not back, as
SIGBUS. The worker died on the spot: no PHP error, no shutdown function, an
empty capture file. Docker gives /dev/shm 64 MB by default, so this was the
normal container configuration.

Measured on the reproducer of phpstan/phpstan#15131 (doctrine/orm +
symfony/http-kernel at level 10, /dev/shm at its docker default), the arena
wants ~65 MB and 3 of 6 runs lost a worker to SIGBUS. Worker count barely moves
that number - 66.6 MB at 2 workers, 68.3 MB at 8 - so it is the payload that
does not fit, not the workers racing to publish it.

So the creator now asks the filesystem what it can give and takes that, minus a
reserve for whatever else lives there. Overflowing an arena is already handled:
the bump cursor passes the end, publishing stops and analysis continues
unshared. The size travels in the header the workers already validate, and the
object's own size tells an attaching worker how much to map.

Windows is unchanged: a pagefile-backed section is committed when it is
created, so it either backs the whole reservation or fails right there.

On the same reproducer, with the same 64 MB: 3 of 3 cycles clean, arena sized
to 56 MB, /dev/shm peaking at 56 MB.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XMcokMDwXGSugGttoDhhJf

Callers probe the index before serializing a value, but building the record
takes long enough for another process to publish the same key meanwhile - and
by the time the CAS discovers that, the loser has already memcpy'd the whole
payload into the arena, committing pages the backing store never gets back.
Probing again right before the copy makes losing cost only the bump it already
took.

The narrowness of the window is why this is a tidy-up rather than the fix for
phpstan/phpstan#15131: duplicates account for ~2.5% of the arena's footprint
(66.6 MB at 2 workers, 68.3 MB at 8 on the reproducer there).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XMcokMDwXGSugGttoDhhJf

…lently

A worker killed by a signal never gets to run any PHP: no error is printed, no
shutdown function runs, and the output the main process reads back is empty. It
also has no exit code, and `onExit` treated that `null` exactly like a clean
exit 0 - quit the process, record nothing. The whole run then said only

    Some parallel worker jobs have not finished.

and when the dead worker happened to be holding the last job, not even that:
the job was already popped, so the analysis reported success with those files
silently unanalysed. That is what made phpstan/phpstan#15131 - workers dying of
SIGBUS on an exhausted shared-memory arena - undiagnosable.

So the signal now travels alongside the exit code, from both mechanisms (the
wait status for a forked worker, react's term signal for a spawned one), and
becomes an internal error naming it. Signal numbers are platform-specific -
SIGBUS is 7 on Linux and 10 on macOS - so TerminationSignal reads the name off
the running platform's own constants. The same report goes to the fixer's
forked child, and an exit that is neither a code nor a signal no longer
swallows whatever the child did write (`pcntl_fork() failed.`, until now).

Covered by e2e/parallel-worker-signal.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XMcokMDwXGSugGttoDhhJf