feat(core): model schema completeness (Schema.closed, open/closed) — Calcite DynamicRecordType pattern

[zzylol]

What

Makes the SQL/PromQL schema difference an explicit, checkable property instead of an implicit one that kept causing "shouldn't a scan emit all the labels?" confusion. Two parts:

1. Docs: Scan.schema reframed as the binding schema (the resolved column set positional ColumnIds index into), not a complete runtime row; SchemaCatalog documented as the column source (input), distinct from the resolved schema it feeds.
2. Schema.closed: bool — the open/closed completeness marker.

Schema.closed

• closed — the schema completely enumerates the columns here: a catalog-backed SQL leaf, or an output fully determined by Aggregate/Project.
• open — a dynamic / superset schema: a schemaless PromQL leaf lists only the (ts, value) floor + referenced labels; the runtime row may carry more.

This is Apache Calcite's DynamicRecordType pattern: a schema starts open at a schemaless leaf and is frozen to closed by the first operator that fully determines its output columns. output_schema_in propagates it:

• passthrough nodes (Filter/Sort/Limit/Distinct/Window/TimeRange/SetOp/Merge/WindowFunc/BinaryOp) inherit the child's closed;
• cross-series Aggregate and Project set true (the freeze);
• per-series reductions (rate/increase, *_over_time) and joins propagate (input.closed, left && right);
• leaves: SQL scan_source → true, PromQL Binder → false.

It decouples completeness from the data model (Source::Table vs TimeSeries), so a future registry-backed PromQL catalog stays open (a metric's labels are per-series and time-varying → superset hint, not a per-row contract).

Why this shape (design survey)

Looked at how typed query IRs over varying schema-strictness handle this — only Calcite spans both open and closed in one IR, which is exactly this project's goal (one IR for SQL ∪ PromQL):

• Calcite — RelDataType per node (binding layer) + catalog (source layer); DynamicRecordType for schema-on-read (CALCITE-1150), frozen to a fixed type on resolution → the model adopted here.
• PostgreSQL / Trino / RisingWave / Ibis — closed-world: schema required (DDL / connector metadata / schema registry / declared). Ibis even validates eagerly (rejects unknown columns) — which is precisely what PromQL can't do, hence the invariant below.
• Prometheus / Thanos promql-engine — fully schemaless; labels resolved at eval; metadata APIs are start/end-scoped (a metric's labels only have an answer relative to a time window).

Invariant: open ⇒ no closed-world validation (PromQL tolerates unknown labels, unlike Ibis/SQL's eager rejection).

Scope / safety

• #[serde(default)] → absent deserializes to false (open) — backward-compatible, conservative.
• No current consumer reads closed — it's a passive marker reserved for label validation / full-output enumeration / cardinality (cost model, Wire workload-level CSE into a cost model #6). Zero behavior change.

Tests

Open→closed freeze (open leaf → per-series rate stays open → cross-series aggregate freezes to closed); serde default (absent ⇒ open); SQL-closed / PromQL-open leaves. Full suite green (141), clippy --all-targets -D warnings + fmt --check clean.

🤖 Generated with Claude Code