run_json: reserve the report channel, so strategy output on fd 1 cannot corrupt a report - #608

…ot corrupt a report

The harness printed the report or a typed failure on fd 1, but the strategy
library it loads runs in the same process and could write to fd 1 as well: one
native printf corrupted a successful report.

- The host saves the caller's stdout as a private report descriptor before it
  parses arguments or loads any strategy, redirects native fd 1 to stderr, and
  writes the report and every typed failure through the saved descriptor.
  Failed-report discard now discards that descriptor.
- A publication guard shared by the main handler and the cleanup keeps a fault
  after a published result or failure from printing a second document; the
  exit status stays nonzero and the late diagnostic goes to stderr.
- FD sink mode keeps the native NDJSON stream on its caller-supplied stream. A
  sink or phase descriptor, or the arena slot, that collides with the report
  channel is refused with the existing run_request_invalid failure.
- docker/entrypoint.sh sends ordinary transpile, compile and bind subprocess
  output to diagnostics; the explicit transpile-only mode keeps stdout.
- The documentation states the limit: the loaded library inherits the saved
  descriptor, so this isolates ordinary native writes and is not a security
  boundary.
- tests/test_run_json_stdout.py with tests/test_run_json_stdout_strategy.cpp
  loads a stub strategy that writes a marker to fd 1 through the real harness:
  clean runs print exactly the expected report with the marker only on stderr,
  a failing run prints exactly one failure document, a fault after publication
  prints no second document, and colliding descriptors are refused.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>

…ut, and tighten the channel tests

When the host's stdout and stderr are the same open file (a 2>&1 wrapper, a
terminal), routing native fd-1 writes to stderr cannot keep them out of the
report stream. The host now notices this before redirecting, writes one stderr
line, "report channel not isolated: stdout and stderr are the same file", and
keeps running: only the isolation claim is lost, so a run that worked before
still works. The docs and the changelog say the isolation holds only when the
two streams stay separate.

argparse help printed through sys.stdout, which in host mode is now fd 1 and
therefore stderr; help for run_json.py and its csv2bin form now goes to the
original stdout again.

A rejected second report publication in library mode no longer points the
caller's stdout at the null device. The wording about how the library reaches
the report descriptor now says it can write it because it runs in this
process, and that the descriptor is non-inheritable so exec'd children do not
get it. Reports are ASCII, so the UTF-8 encoding of the channel changes no
bytes. New cases: merged streams, help on stdout, descriptor relocation with 3
and 4 occupied, non-ASCII failure text on the channel, and the second library
publication. The doc citations that the source shift moved are re-pointed.

Two sentences introduced by 67ade9d ("run_json: reserve the report channel, so
strategy output on fd 1 cannot corrupt a report") are replaced on purpose.
In docs/pages/memory-management.md, "Native code runs in the same process and
inherits the saved descriptor, so code that deliberately writes through that
inherited file description can s..." is replaced by the sentence that the
library can write the descriptor because it runs in this process and that the
descriptor is non-inheritable. In docs/pages/scratch-tables.md, "The saved
report descriptor is inherited by native code in this process, so this
separation is transport isolation rather than a security boundary." is
replaced by the same corrected wording; the limit it states (not a security
boundary) is kept.

Co-Authored-By: Claude Sonnet 5.5 <[email protected]>