Evaluate sequence accessors per row in SELECT-list contexts (0A000 today)

[EnRaiha]

Summary

Sequence accessors in SELECT-list over table rows raise 0A000 by design
(constant contexts — FROM-less SELECT, VALUES — evaluate for real, see
#307). Per-row evaluation is the remaining step: SELECT nextval('s') FROM t should advance per output row like PostgreSQL.

Scope

Needs a plan-level CP marker plus a post-DP stamping stage in the control
response path that preserves output-row order (single-source scans first;
joins/unions ordering documented). RETURNING per-row evaluation rides the
same seam.

Related: #294, #303, #307

Reproduction

CREATE SEQUENCE s;
CREATE COLLECTION t (id BIGINT, v TEXT) WITH (engine = 'kv');
INSERT INTO t (id, v) VALUES (1, 'a'), (2, 'b');
SELECT id, nextval('s') FROM t;   -- 0A000 today; PostgreSQL: advances per row

[farhan-syah]

Still open. PR #316 registers nextval/currval/setval so they pass the plan-time existence gate, which removed the reason the 0A000 was raised. That branch restores the refusal deliberately and pins it with coverage, so the behaviour reported here is unchanged.

Measured while investigating: with the accessors registered and no per-row evaluation, SELECT nextval('s') FROM t returned one empty cell per row and no error. nodedb-query/src/functions/eval.rs ends with eval_geo_function(name, args).unwrap_or(Value::Null), so an unmatched name yields Value::Null for every row. A silent empty cell is worse than the refusal, so the resolver now refuses the scope instead.

The gate is scope-based, at nodedb-sql/src/resolver/expr/functions.rs. A scope owning a relation, or an enclosing correlated scope, is refused. A FROM-less SELECT is unaffected and still evaluates for real. Joins and unions are covered by the same gate, so no unordered shape can produce values.

Findings relevant to implementing per-row evaluation:

• The stamping stage this needs does not exist. nodedb/src/control/gateway/fuser.rs is the only post-Data-Plane row-level touch point in the Control Plane, and it concatenates multi-vShard payloads in arrival order, not output-row order.
• Payloads return as opaque MessagePack, and the document read path supports raw passthrough via encode_raw_document_rows, so a stamping stage must decode and re-encode every row shape on every engine.
• A plan holding a sequence call is already not cache-eligible, so re-planning per execution is guaranteed and does not need new machinery.
• Output ordering must be defined for broadcast scans before values can be stamped.