fix(worker): preserve delivered MCP errors

[WarGloom]

What changed

A supervised indexing worker now exits successfully when it has written a
complete MCP response, even when that response is an application-level tool
error. The parent can therefore read and return the real error instead of
replacing it with a generic exit_nonzero / "crashed on a file" diagnosis.

Response-file open, write, or close failures still produce a nonzero worker
exit. A focused shell regression covers both the direct worker transport and
the user-facing supervisor behavior.

Why

The worker process status represents transport health, while the serialized MCP
payload represents tool success or failure. Reusing the CLI presentation exit
code for both layers caused the supervisor to discard valid error payloads.

This fixes the false-crash classification described in #1211 and complements
#1258, which addresses that issue's project-name-to-root-path resolution case.

Validation

• CCACHE_DISABLE=1 ./scripts/build.sh — passed
• git diff --check — passed
• bash -n tests/test_worker_error_response.sh — passed
• shellcheck tests/test_worker_error_response.sh — passed
• focused end-to-end regression included for clean CI execution; its local run
  was blocked before the assertion by an already-running daemon from a different
  build cohort, which was deliberately not terminated

Checklist

• Commit is signed off (DCO)
• Change is focused on one tracked bug
• Regression coverage included

[DeusData]

Reviewed this one closely — thank you, it is a genuinely good change and the reasoning in the description is the part I appreciated most.

Separating the two layers is the right call: the worker's process status describes transport health, while the serialized payload describes tool success or failure. Collapsing those meant a perfectly valid MCP error response was thrown away and reported to the user as exit_nonzero / "crashed on a file", which is about as misleading as a diagnostic can get. Exiting zero once the response is fully written, and nonzero only when the transport itself failed, puts the exit code back in charge of the thing it can actually speak to.

A few things I checked rather than assumed:

• fputs(...) >= 0 && fclose(...) == 0 is the correct success test — fputs returns a non-negative value on success and EOF on failure, and the fclose result is what catches a deferred write error.
• Genuine crashes still surface: a worker that dies never reaches this path, so the parent still sees the signal or a nonzero status.
• Scope is coherent — src/main.c, the new regression, and the test.sh wiring that runs it. Nothing rides along.

One entirely non-blocking nit: the failure path exits with SKIP_ONE, which is enum { SKIP_ONE = 1 } from constants.h — a loop-arithmetic constant. The value is right, but as an exit status it reads oddly next to CLI_SKIP_ONE, or a plain 1. Worth a moment if you touch this again; definitely not worth another round-trip on its own.

Same question as on #1368: this is still a draft, so I have not promoted it myself. Mark it ready (or say so here) and I will merge — CI is 28/28 green. If you are still polishing, please do; this one changes worker exit semantics, so I would much rather have the version you consider finished than the one that happens to be green tonight.

[DeusData]

Thank you for marking this ready and for preserving the delivered MCP error instead of replacing it with a transport-level fallback. I have routed it at high priority in 0.9.1-rc. The PR is back in the maintainer review queue; that queue is currently full, so the final re-review may take a little time.

[DeusData]

Thank you — this is exactly the right separation of layers: the process status speaks for transport health, the serialized payload speaks for the tool result, and conflating them is what made the supervisor invent 'crashed on a file' out of a perfectly delivered error. Tying worker exit 0 to the response actually being written (and hard-failing when the write itself fails) makes the protocol strictly more honest in both directions. The shell regression covering both the direct worker transport and the user-facing supervisor behavior is much appreciated — as is the honest note about the daemon blocking your local run. Great to have you as a repeat contributor!