Hermes Runner: data race on scanner + r.running across Prompt/Start

[rafeegnash]

Problem

The Hermes Runner's Prompt goroutine reads r.scanner.Scan() without holding r.mu, while Start also uses the same scanner during the init handshake. Two overlapping prompts could race on the same scanner and deliver a response to the wrong consumer (matched by ID, but only after stealing lines from the other prompt). r.running is also touched lock-free.

go test -race would flag this — it isn't run on the package.

Where

internal/hermes/runner.go:268 — Prompt reading r.scanner.Scan()
internal/hermes/runner.go:115-181 — Start handshake on same scanner
internal/hermes/runner.go — r.running writes/reads without atomic or mutex

Fix

1. Move scanner reads into a single goroutine started in Start (a dispatch loop)
2. Maintain a map[int64]chan response under r.mu keyed by request ID
3. Each Prompt allocates an ID, registers a channel, sends the request, and reads its own channel
4. Convert r.running to atomic.Bool

Acceptance criteria

• go test -race ./internal/hermes/... clean
• New test: two concurrent Prompt calls on the same Runner each get their own response, no cross-talk
• Bridge process death is observed by the dispatch loop and propagated to all waiting Prompt channels via context cancel

Labels

bug, priority: critical (use defaults available in clanker-cli)

[rafeegnash]

Fixed in upstream bgdnvk#187 (merged). The PR introduces a single dispatcher goroutine that owns the scanner, per-ID inbox routing for responses, and a promptMu serialising overlapping Prompt() calls. go test -race ./internal/hermes/... passes; the data race on scanner + r.running is gone. Will land here on the next fork sync.