feat(sql): evaluate sequence accessors in constant contexts and kv projections

[EnRaiha]

Problem

Two gaps kept sequence accessors and scalar expressions out of SELECT
evaluation:

1. kv scans dropped SELECT projections — KvOp::Scan carried neither
   the projection list nor computed columns, so expression projections
   over kv collections were never evaluated: the column surfaced as NULL
   at response shaping (SELECT 1 + 1 FROM kv returned an empty column),
   and accessors in a kv SELECT list could not raise their typed error.
2. Constant contexts had no registry access — SELECT nextval('s')
   without a FROM clause and explicit VALUES (nextval('s')) cells fold
   at plan time inside nodedb-sql, which has no sequence registry; they
   raised the 0A000 reserved for row-scope escapes instead of evaluating.

Fix

• KvOp::Scan gains projection and computed_columns (same wire format
  as DocumentOp::Scan / ColumnarOp::Scan); the scan converter forwards
  them and the kv scan handler applies projection + computed per row after
  sorting, through the evaluator the document path uses. Evaluation errors
  surface with their typed code (division -> 22012, accessors -> 0A000).
• Constant folding in nodedb-sql gains a nesting-safe, thread-local
  sequence-evaluator hook (default absent: behaviour unchanged). The
  control plane installs it around each planning call over its sequence
  registry, so nextval/currval/setval with fully folded arguments
  evaluate exactly once, in expression order, and registry errors surface
  as plan errors naming the sequence (same class as the DEFAULT path).
• Row-scope contexts over a table (WHERE, ORDER BY, SELECT list over
  rows) keep raising 0A000.

Tests

Wire coverage: kv scalar projections evaluate per row (upper(v),
1 + 1); accessors in a kv SELECT list raise 0A000; plain projections
unchanged. Constant contexts: FROM-less nextval advances and currval
reads back in-statement; consecutive statements continue the sequence;
VALUES cells advance per row; setval returns its value; missing
sequence raises a plan error naming it. All prior sequence suites stay
green (DEFAULT across engines, expression-context classification).

Part 2 of issue #294 (see the issue for the split). The branch history
includes Part 1 commits until the parts merge; the final diff against main
will contain this change alone.

issue #294 (Part 2), #295

Cache safety

A plan that folded a stateful accessor at plan time must not be admitted
to the physical-plan cache: the folded literal would replay the same value
forever. The fold hook records whether it produced a value, and planning
forces such statements to re-plan on every execution (DataDependent
eligibility). The parameterized path does not admit plans to the cache at
all.

Semantics boundaries

• Row-scope DML expressions (UPDATE SET, ON CONFLICT DO UPDATE, DELETE
  WHERE, RETURNING, window functions) keep raising 0A000 — no
  once-folded value is silently applied per row. Per-row evaluation for
  SELECT-list projections over tables is a follow-up.
• EXPLAIN plans without advancing the registry (metadata-purpose planning
  folds the accessor to a placeholder), matching PostgreSQL.
• Known pre-existing gap (unrelated to accessors): INSERT..SELECT with a
  kv-engine source drops expression projections in the copy_rows
  column-map (silent NULL) — tracked in INSERT..SELECT with a kv-engine source silently NULLs expression cells #311. Per-row SELECT-list
  evaluation is tracked in Evaluate sequence accessors per row in SELECT-list contexts (0A000 today) #314; the 42704 promotion for unknown-sequence
  DEFAULTs in Unknown sequence in DEFAULT raises 42601 instead of 42704 #313.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[EnRaiha]

Superseded by #303 — the change set is merged into it as a single commit.