fix: log worker crashes at warn level instead of debug

[luminalpark]

A worker script that dies after boot (non-zero exit status) currently logs the same debug-level "restarting" message as a clean FRANKENPHP_LOOP_MAX recycle — same level, same message text. At the default log level a crash is therefore invisible to operators:

• the in-flight request surfaces as an empty 500 (0 bytes after normal processing time),
• the application never gets to log anything — the script died mid-request,
• and exit_status, the one datum needed to triage the death, is only obtainable by running the whole server at debug level.
  We hit this in production (Shopware on FrankenPHP 1.12.4, worker mode): frankenphp_worker_crashes was steadily incrementing at ~0.03% of requests, each crash converting one user request into an empty 500, with zero trace in any log — app log, stderr, or FrankenPHP's own output. It took us three debugging sessions to find the Prometheus counter, and we still could not see the exit statuses.

This is a regression

Up to v1.2.x the crash path was clearly distinguished (worker.go @ v1.2.5):

if fc.exitStatus == 0 {
    if c := l.Check(zapcore.InfoLevel, "restarting"); c != nil { ... }
} else {
    if c := l.Check(zapcore.ErrorLevel, "unexpected termination, restarting"); c != nil {
        c.Write(zap.String("worker", absFileName), zap.Int("exit_status", int(fc.exitStatus)))
    }
}

That error-level line is, for instance, how the reporter of #774 noticed their problem at all. Somewhere in the worker-thread refactoring both paths converged on debug-level "restarting".

What this PR does

• The crash branch of tearDownWorkerScript (non-zero exit after boot, StopReasonCrash) now logs at warn with the historical, distinct message "unexpected termination, restarting", keeping the worker / thread / exit_status attributes. Warn matches the neighboring worker-failure logs in the same function; happy to bump it to error (the 1.2.x level) if preferred.
• Clean restarts (exit 0, LOOP_MAX recycling) stay at debug — they are frequent and healthy, raising them would be noise.
• Fixes a mismatched guard in the watcher-enabled boot-failure path: Enabled() checked LevelError while LogAttrs wrote LevelWarn.
• Adds testdata/crashing-worker.php (boots fine, exit(1) on its second request — the exact scenario of the code comment) and a test asserting the warn-level line with exit_status=1 is emitted.
  No behavior change beyond logging.
  Fixes Worker crashes are logged at debug level only: invisible in production, in-flight request becomes an empty 500 #2601

[dunglas]

LGTM, but I wonder why we changed that behavior in the first time.