fix: preserve Ordered() set before Parallel()

[tr1v3r]

Problem

Ordered()'s contract says it applies to "the current parallel section ... or the next one if called before it" (export.go, stream.go godoc). The implementation broke the second half: Parallel() unconditionally executed s.ordered = false, so

stream.SliceOf(src...).Ordered().Parallel(4).Map(jitter).ToSlice()

returned elements in completion order instead of encounter order — the explicitly requested ordering was silently dropped (audit finding M1; PoC: ordered-before-parallel output ≠ input order with a reversed-cost jitter map).

Root cause

ordered=false was meant to give new sections their documented default (unordered). But the zero value of the flag already provides that default on a fresh streamer, so the unconditional reset only ever destroyed an explicit Ordered() set before Parallel().

Fix

Drop the reset line — s.ordered keeps whatever the caller chose; Ordered() now applies to the section a later Parallel() opens, exactly as documented. The godoc wording is aligned ("Sections run unordered unless Ordered() was set on the stream (before or after the Parallel call — the flag carries into the section)").

Test evidence

• New TestParallelV2_OrderedBeforeParallel: Ordered().Parallel(4).Map(reversed-cost jitter) reproduces encounter order (-race green).
• Existing interaction coverage on this stack stays green: TestParallelV2_MidChainParallelKeepsOrderedSection (Parallel(2).Ordered().Map(j).Parallel(4).Limit(3) == [0 1 2]).
• go build / go vet clean, go test ./... -race -count=1 all ok, golangci-lint 0 issues.

Stack note

Stacked on #19 (fix/midchain-parallel-section): that PR keeps s.ordered = false placed after the flush-adoption, this PR removes it. Merge #19 first; GitHub will retarget this PR to master automatically.