v0.74.0 — @table streaming consumption

Streaming-consumption release. One informational §3.4.4 addition: implementations MAY (and for the CSV-replacement use case typically SHOULD) expose a row-by-row streaming API alongside the materializing one. No grammar change, no wire change. First-port implementation: protowire-go v0.75.0 ships pxf.TableReader over io.Reader.

What changed

Section 3.4.4 grows a "Streaming consumption" paragraph pinning the contract for row-by-row @table consumption:

• Tools MAY expose a row-streaming API alongside the materializing one.
• Rows in source order.
• Per-row arity and the v1 cell-grammar rule MUST be enforced as each row is consumed (not deferred to end-of-input).
• Working-set memory SHOULD be bounded by the size of the largest single row, not by the size of the row sequence.
• Streaming and materializing APIs that coexist in the same implementation MUST produce byte-identical row sequences for the same input.

The change is informational — clarifying language that §3.4.4's existing "consumer-interpreted side-channel" framing already permitted. Without the explicit nod to streaming, port maintainers reasonably read v0.73.0's text as mandating full materialization (the v0.73 reference implementation only shipped the materializing path).

Backward compatibility

• No grammar change, no wire change.
• Ports that ship only the materializing API remain spec-conformant. The streaming API is a MAY, not a MUST.

Conformance

A port that exposes a streaming row API on v0.74.0+ MUST satisfy the contract above. A port that doesn't expose one is unaffected.

See CHANGELOG.md for the full entry.