Go Concurrency Review

This codebase multiplexes concurrent property tests over a shared subprocess via channels. Concurrency bugs here are subtle and the race detector only catches about half of real-world Go concurrency bugs. Think carefully.

Core principle: be explicit about ownership

Every piece of mutable state must have a clear owner. Either:

• One goroutine owns it — no synchronization needed, but document it (e.g., "only called from readLoop")
• A mutex protects it — every access, including reads, must hold the lock
• A channel mediates it — data flows from producer to consumer with happens-before guarantees
• It's immutable after initialization — set before any goroutine can read it, preferably via sync.Once

If you can't immediately name the owner of a field, that's a bug.

This codebase's concurrency architecture

See references/architecture.md for the full map of what's protected by what. The key patterns: