fix(extensions): W5 review follow-ups — buffered stdin reader + comment cleanup

[stack72]

Summary

• Fix readLine() in subprocess_entry.ts to use a persistent remainder buffer, correctly handling multiple newline-delimited messages in a single stdin read (adversarial review medium finding from feat(extensions): W5 — per-fingerprint import URLs + subprocess test harness (swamp-club#290) #1361)
• Use streaming TextDecoder to handle multi-byte UTF-8 at chunk boundaries (adversarial review low finding)
• Remove W5 task-referencing comment blocks from extension_loader_test.ts and module_reload_bench.ts per CLAUDE.md conventions (code review suggestion)

Test plan

• All 17 subprocess harness + module-reload tests pass
• deno check clean
• deno lint clean
• deno fmt clean

🤖 Generated with Claude Code

[github-actions]

CLI UX Review

Blocking

None.

Suggestions

None.

Verdict

PASS — This PR makes no user-facing changes. All three modified files are internal testing/benchmarking infrastructure:

• subprocess_entry.ts is the test harness subprocess worker (not a CLI command)
• extension_loader_test.ts and module_reload_bench.ts are test/benchmark files

The stdin-reader bug fix and comment cleanup have zero impact on CLI output, help text, error messages, or JSON mode.

[github-actions]

Code Review

Clean, focused PR that fixes a real bug in the subprocess stdin reader and removes task-referencing comments per CLAUDE.md conventions.

Blocking Issues

None.

Suggestions

None — this is a well-executed fix.

Details

subprocess_entry.ts — buffered readLine() fix:
The old implementation had a correctness bug: if multiple newline-delimited messages arrived in a single Deno.stdin.read() call (e.g., "msg1\nmsg2\n"), line.includes("\n") would return true and .trim() would collapse both messages into one return value. The new persistent-remainder approach correctly extracts one line at a time and preserves the rest for subsequent calls. The { stream: true } on TextDecoder properly handles multi-byte UTF-8 split across chunk boundaries. The module-scope remainder is appropriate since this is a single-process subprocess entry point.

Comment removals:
Both comment removals are correct — W5 task references removed per CLAUDE.md ("Don't reference the current task, fix, or callers"), while the threshold comment in module_reload_bench.ts is correctly retained as it documents a non-obvious constraint.

Convention compliance: License headers present, no new any types, no fire-and-forget promises, no libswamp internal path imports from outside the boundary. All changes are within scope.

[github-actions]

Adversarial Review

Critical / High

None found.

Medium

None found.

Low

1. src/infrastructure/testing/subprocess_entry.ts:53-56 — Streaming decoder not flushed on EOF. When Deno.stdin.read() returns null, the code returns whatever is in remainder but never calls decoder.decode(new Uint8Array(0)) (i.e., a final decode without { stream: true }) to flush any bytes the streaming TextDecoder may have buffered from an incomplete multi-byte sequence. If stdin closes mid-UTF-8 codepoint, those buffered bytes are silently lost. In practice this cannot happen here — the harness sends complete JSON over a pipe — so the data path is safe. Noting it only because the { stream: true } fix was explicitly motivated by multi-byte correctness; a one-line flush would close the loop.

   Suggested fix (optional):

   if (n === null) {
     remainder += decoder.decode(new Uint8Array(0)); // flush streaming decoder
     const last = remainder.trim();
     remainder = "";
     return last;
   }

2. src/infrastructure/testing/subprocess_entry.ts:47-48 — .trim() discards leading/trailing whitespace from JSON lines, which is benign for well-formed JSON but could mask a framing bug. If the harness ever accidentally sent a message with leading whitespace that was semantically meaningful (not JSON), trim() would silently alter it. Given the protocol is strictly JSON, this is a non-issue, but worth noting for anyone extending the protocol later.

Verdict

PASS. The buffered readLine() rewrite correctly handles multiple messages coalesced in a single stdin read, partial reads split across chunks, blank lines, and EOF with/without trailing data. The streaming TextDecoder properly handles multi-byte UTF-8 at chunk boundaries. Comment removals are consistent with CLAUDE.md conventions. No blocking issues.