feat: max_in_flight — bounded stream handoff

[mvallebr]

Summary

Adds max_in_flight — controls how many items a producing stream can emit ahead of the downstream consumer. Default 1 preserves exact current lockstep behavior.

API

step("name", fn=process, max_in_flight=30)

Implementation

DAG model:

• Step.max_in_flight and DagNode.max_in_flight default to 1
• Serialized in DAG JSON (always present)
• Validated at build time: must be int >= 1
• Runner consults compiled DAG, never Step directly
• Sub-pipeline expansion preserves configured max_in_flight

Sync runner:

• New BoundedIterator (deque-backed) wraps progressive stream outputs when max_in_flight > 1
• Fan-out: BoundedIterator applied BEFORE itertools.tee — bounds producer at source

Async runner:

• Publish queues sized by max(100, node.max_in_flight) — backward compat at default
• Unroll queues use producer node's max_in_flight

Tests: 20 new (10 build-time + 5 sync + 5 async).

• Explicit build-time check for invalid types (e.g. boolean True rejected).
• Explicit runner contract test to guarantee that both sync and async executors use compiled DagNode.max_in_flight rather than direct Step values.
• Build-time validation for generated adapter steps (max_in_flight=1).

Known v1 limitations:

• Async: queue minimum of 100 needed to prevent pump deadlock with sequential put across multiple consumer queues. max_in_flight > 100 honored exactly.
• Sync fan-out: itertools.tee internal buffer not bounded per-branch. Source bounded, but slow branches can accumulate tee backlog.
• Full bounded handoff per-branch requires deeper executor redesign (separate pump tasks per consumer queue, tee replacement).

Corpus: All snapshots (including the new max_in_flight_threadpool.py) updated and fully validated.

445 tests passing.