Improve PHPT hang diagnostics and fix flaky socket tests

[matyhtf]

Summary

• keep the local TCP listener alive until the closed-socket coroutine finishes its assertions
• emit durable [PHPT START] and [PHPT END] records with worker ID, status, and duration in CI logs
• report every active parallel worker and its current PHPT every 30 seconds; add --status-interval to configure or disable this heartbeat
• enforce an absolute per-test timeout and handle stdout/stderr EOF independently
• stop waiting for output pipes inherited by descendants after the direct PHPT process exits
• make sendfile_client_reset.phpt deterministic, bounded, and isolated with a unique temporary file
• isolate unixsocket2.phpt with a unique Unix socket path and explicit cleanup

Root causes found

• closed.phpt: the listener was released while Socket::connect() was yielding, allowing Linux to reset the queued connection and retain ECONNRESET instead of testing post-close EBADF
• sendfile_client_reset.phpt: the random file could be smaller than the 2 MiB client-close threshold, leaving recv() blocked on an HTTP/1.1 keep-alive connection
• the old runner printed TEST progress without a durable newline and did not track the active test per worker
• the old timeout loop could stop reading when only one pipe reached EOF, then block forever in proc_close()
• fatal-error PHPTs may leave server descendants holding inherited output pipes even though the direct test process has already exited
• unixsocket2.phpt reused a repository-local socket path, so an initial transient failure poisoned every retry with EADDRINUSE

Validation

• closed socket PHPT passed 20 local repetitions
• synthetic parallel hang test produced exact START, RUNNING, timeout, and END records
• inherited-pipe fixture completed immediately instead of waiting for its descendant
• close_before_resume.phpt and exec_twice.phpt both PASS locally and in Linux x86 CI in about 0.2 to 0.3 seconds
• sendfile_client_reset.phpt PASS in Linux x86 full CI in 0.536 seconds
• unixsocket2.phpt passed five consecutive local runs
• Linux Unit run: x86_64 full suite SUCCESS in about 5m24s; ARM64 full suite SUCCESS in about 6m02s
• Windows Unit run: SUCCESS, including IOCP socket and thread groups

macOS still reports existing platform-sensitive failures in swoole_coroutine_lock/lock.phpt and swoole_curl/error.phpt; neither is a runner timeout or worker-state failure.