Investigate duplicate history consumption in parallel Bash replay #384

Observed failure

While validating the unchanged public CodeAPI service code during the #377 import, the existing Bash replay regression test failed intermittently on Ubuntu / Bun 1.4.4:

generateBashReplayPreamble - command substitution pending emission > replays parallel calls with identical signatures after call-site line numbers shift

The two background calls have identical tool names and inputs, and history contains distinct first / second results. The replay exited successfully with no pending calls but produced:

{"slot":"first"}{"slot":"first"}DONE

The assertion expects both distinct results, so this could indicate history consumption or shared replay-state cleanup racing between background calls. The root cause is not established; this is more than a timeout assertion.

Evidence and scope

• Failing CI job: https://github.com/ClickHouse/ai/actions/runs/42853235232/job/129959445493
• Public baseline imported through 4b41f3a97d9cafaf11498b62b1ec6cb9e91c68f0.
• 📦 feat: Add Verified npm Worker Releases #377 changes release packaging and CLI naming, not service/src/preamble-bash.ts or this test.
• 1,245 service tests passed, 17 skipped, and this one failed.
• The same focused test passed 20 consecutive local runs on macOS / Bun 1.4.4; it also passed the earlier CI run. The frequency and Linux-specific behavior need investigation.

Reproduction / follow-up

cd service
bun ci
bun test src/preamble-bash.test.ts -t 'replays parallel calls with identical signatures' --rerun-each 100

Run on Linux, preferably under competing process load. Instrument consumed-history keys, counter allocation, lock lifetime, and EXIT cleanup across the parent shell and both background tool calls. Preserve the existing assertion: each history entry must be consumed at most once and both distinct results must survive the replay.