fix: close parallel section on mid-chain Parallel

[tr1v3r]

Problem

A mid-chain Parallel(n) call did not actually close the current parallel section: stream.go's
Parallel() invoked s.ensureFlushed() but discarded its return value, so the section's
fused stages and the pre-section upstream stayed on the streamer. The documented contract
("A mid-chain call closes the current section and opens a new one" — export.go / README
"sections overlap" pipeline-parallelism) was silently violated:

• The two sections' fused stages merged into ONE pool sized by the second Parallel's n:
  Parallel(8).Filter(slow).Parallel(2).Map(...) ran Filter with peak concurrency 2, not 8 —
  the first section's worker count was silently dropped.
• An Ordered() section lost its ordering guarantee at the next Parallel:
  Parallel(2).Ordered().Map(f).Parallel(4).Limit(3) returned [f(192), f(193), f(194)]
  instead of [f(0), f(1), f(2)] — Limit selected wrong elements.
• Advertised pipeline parallelism ("sections overlap") did not exist.

(Element values were unaffected — results stayed correct as multisets, which is why the
existing test suite, which only checks multisets, never caught it.)

Root cause

ensureFlushed() returns a new streamer carrying the flushed pipeline (next.seq) and a
cleared fused. Parallel() called it for its side effect only; since Go has no such side
effect here, the call was a no-op and the returned flushed pipeline was thrown away.

Fix

Adopt the flushed streamer before opening the new section:

s = *s.ensureFlushed()
s.parallelSize = n
s.ordered = false

The closed section's output becomes the new section's upstream. Each section now runs on its
own pool sized by its own Parallel call, and adjacent sections overlap naturally: the
downstream section's feeder pulls the upstream section's iter.Seq lazily, so both pools are
active concurrently with bounded backpressure — no channel bridge or extra machinery needed,
and the README's "sections overlap" wording becomes true as-is (no doc rewording required).

Cancellation still propagates cleanly across the chain (downstream terminal exit → downstream
cancel+drain → its feeder observes ctx on the next element → upstream consumer unwinds →
upstream cancel+drain); guarded by TestParallelV2_MidChainShortCircuitNoLeak
(runtime.NumGoroutine polling, same pattern as the existing single-section leak test).

Tests

• TestParallelV2_MidChainParallelSeparatePools — section A must run on exactly its own
  2-worker pool even when Parallel(8) follows (fails on master: peak reaches 8).
• TestParallelV2_MidChainParallelKeepsOrderedSection — ordered section + mid-chain
  Parallel + Limit(3) must select [0 1 2] (fails on master: [192 193 194]).
• TestParallelV2_MidChainShortCircuitNoLeak — chained sections + infinite source +
  Limit short-circuit leaves no leaked goroutines.

Verified: go test ./... -race -count=1 green; new tests green under -race -count=3;
golangci-lint 0 issues.

Out of scope (follow-ups)

• Ordered() called before Parallel() is still reset (separate PR).
• Parallel(n <= 0) remains a no-op even with an open section (separate issue).