[cli] batch mode silently drops Debug ghost-effect output (flushDebugOutput never runs per item)

[sunholo-voight-kampff]

Found while fixing #607 (PR #690); pre-existing and mechanically unrelated to that fix, so filed separately rather than bundled.

flushDebugOutput(effCtx) is called once, in the single-file branch of cmd/ailang/main_run_exec.go:574. executeBatchItem never calls it.

So under ailang run --batch, every Debug ghost-effect log is collected into the per-item effect context and then discarded when that item's context goes out of scope. Debug output works when you run a file directly and silently vanishes when you run the same file in a batch — which is the worst shape for a debugging facility, since the batch case is exactly when you need it.

Measured: grep -rn flushDebugOutput cmd/ailang/ returns the definition (run_helpers.go:715) and exactly one call site (main_run_exec.go:574), inside the non-batch else branch.

Suggested acceptance

• executeBatchItem flushes debug output per item (labelled with the input, so N items do not produce an unattributable stream).
• A test running a batch of 2 where both items emit Debug output and both appear.
• Neutering the flush must red that test.

Related: #607, PR #690, #691.

[sunholo-voight-kampff]

Fixed — squash 29ad1c559 via #711. The issue was auto-closed by Fixes #692 at merge; this comment carries the verdict.

Reproduced first-party at 6dd525c58 before any work, with a fixture calling std/debug.log("HELLO-FROM-DEBUG"):

command	occurrences
ailang run --debug --entry main dbg.ail	1
ailang run --debug --entry main --batch dbg.ail in1 in2	0, while reporting Batch complete: 2/2 succeeded

Two notes beyond the suggested acceptance:

• Attribution does not use the batch header. ─── [i/n] <input> is printed inside if !quiet and Debug shares its stream, so under --quiet a bare per-item flush would still be unattributable. The flush takes an explicit label and emits [<input>] <message>; the single-file path passes an empty label and its bytes are unchanged (pinned by a test asserting an exact unprefixed line).
• The flush is deferred, placed immediately after the effect context is constructed, so it also runs for an item that fails — including one that calls exit(), which [cli] Batch mode: a module calling exit() inside a ba... #607's recover turns into a per-item error. A failing item's Debug logs are the ones you most want.

Four subprocess tests in cmd/ailang/main_run_batch_debug_test.go. The neutering mutation (if false { flushDebugOutput(effCtx, input) }) was asserted LANDED and BUILDS; three of the four go red, and the inverse arm (full package with those four skipped) is rc=0, so they are the killers rather than bystanders.

One of them didn't start that way: the severity-filter test as first written asserted only that a below-threshold line was absent, and it survived the mutant — an absence is satisfied just as well by "nothing was ever flushed". It now carries a known-positive control (an ERROR-severity line that must survive --log-level warn) and reds on that assertion.