fix(A22/A23/A25/A26/A27/A29/A30/A36): 查询层 8 项缺陷根治 + 单一语义收敛

每项都先用可执行探针复现出**错误的实际输出**，再修根因、补永久回归套件
（tests/v080-query-layer.test.ts，8 项 × 4 引擎 + 跨引擎项，共 111 断言）。

A22 GROUP BY 引用 SELECT 别名
  修复前：`SELECT g AS grp, COUNT(*) FROM t GROUP BY grp` 抛
  `COLUMN_NOT_FOUND Unknown column "g" in SELECT list` —— 错误信息与真正原因
  （GROUP BY 用了别名）无关，因为 grp 取到 undefined 使全表并成一组，
  投影阶段又发现 g 不在输出行里。
  修复：GROUP BY 项先解析回**基列**（别名 → 源表达式）再分组，输出键与
  "按基列分组"完全一致。

A23 HAVING 引用未出现在 SELECT 里的聚合
  修复前：`SELECT g FROM t GROUP BY g HAVING SUM(n) > 25` → `[]`
  （SUM(n) 从未被求值 → HAVING 的键在分组行里不存在 → UNKNOWN）。
  修复：需要计算的聚合 = SELECT 列 ∪ HAVING 中的聚合（并集），
  并在 HAVING **之后**才把行收缩为 SELECT 输出键（否则又变回 []；
  顺序错了会双向出错：先投影 → 空结果，不投影 → 泄漏内部聚合列）。

A25 带表前缀的聚合参数恒 0
  修复前：`COUNT(t.n)` → 0、`SUM(t.n)` → null（行键是 n，直接取 row['t.n']
  得 undefined 再被"过滤 NULL"剔除，**且不报错**）。
  修复：新增唯一列引用解析 resolveColumnValue（前缀剥离 → 精确 → 唯一后缀），
  聚合识别统一为 parseAggregateExpression —— 此前"是否聚合"与"如何求值"
  用两条不同的正则。取不到列改为抛 COLUMN_NOT_FOUND，不再静默计 0。

A26 UNION 尾部 ORDER BY/LIMIT 归属错误
  修复前：`A UNION B ORDER BY id DESC` 只排 B；`... LIMIT 3` 返回 4 行
  （parser 把子句挂在右侧 SELECT 上，AST 没有复合查询级字段）。
  修复：SelectUnionStatement 增加 orderBy/limit/offset，parser 把子句**上移**
  （移动而非复制，否则 LIMIT 应用两次），executor 在合并+去重后统一排序/切片。

A27 DISTINCT 作用在投影前
  修复前：`SELECT DISTINCT g AS d FROM t` 返回 4 行 a,a,b,b
  （对 {id,g,n} 原始行去重），而 `SELECT DISTINCT g` 返回 2 行。
  修复：DISTINCT 移到投影后（作用于输出列）；ORDER BY 的应用时机随之拆成
  "引用输出列 → 投影后" / "引用非输出列 → 投影前"，两者互为因果必须一起改。

A29 maxRowsPerQuery 静默截断写入
  修复前：maxRowsPerQuery=2 时 `INSERT INTO dst SELECT id FROM src`（4 行源）
  只写 2 行并报成功 —— 不是"限制查询规模"而是**静默丢数据**。
  修复：行源不截断（executeSelect 增加 purpose='source'），写路径显式报错。

A30 INSERT 值多于目标列静默丢弃
  修复前：`INSERT INTO t (id,g) VALUES ('9','z','LOST')` 报成功、'LOST' 消失。
  修复：显式列名时解析期拦截（PARSE_ERROR），未给列名时 executor 对照 schema
  拦截（VALIDATION_ERROR）——两种情况都需要，因为前者无需 schema。

A36 派生表别名引用
  修复前：`SELECT d.id FROM (SELECT id, g FROM t) AS d` 返回 `[]`，
  而同义的 `SELECT id FROM (...) AS d` 正确。
  修复：抽出 normalizeUnprefixedReferences（WHERE/ORDER BY/GROUP BY/SELECT
  四类引用统一剥离别名前缀），非 JOIN 单表路径与派生表路径共用同一规则。

连带根治（修复过程中发现的两个更底层问题）：

1. **同步抛错穿过 async 边界**：`executor.execute()` 里 `return this.executeXxx(stmt)`
   的同步前导段若抛错（arity/校验），异常成为**同步抛出** ——
   `await expect(db.query(...)).rejects...` 的断言不生效、`.catch()` 永不执行。
   现统一包一层 try/catch，保证任何错误都是 rejected promise。

2. **缺列的行形状不一致**：validateRow 此前"值为 undefined 就不落键"，
   于是 `INSERT INTO t (id,g) VALUES ('9','z')` 的行里没有 n 键 →
   `SELECT id,g,n FROM t` 抛 COLUMN_NOT_FOUND: n，而 `SELECT * FROM t` 正常。
   现在缺列且无 default → 显式补 null（SQL 语义），行始终含全部 schema 列；
   ALTER ADD 同步在已有行上物化 null，使"内存视图"与"重启后视图"一致。

验证：全量 83 套件 / 1589 测试通过（含 Aria 5 万行索引竞态、KVStore 持久化）；
typecheck(src+tests) 与 lint 零错误。

src/engine/memory.ts

@@ -158,6 +158,17 @@ export class MemoryEngine implements IStorageEngine {
           pks.add(pk);
         }
       }
+      // v0.8.0（B-1）：ADD 列在**已有行**上物化为 NULL。
+      //
+      // 行校验契约（table/validation.ts）保证"行含全部 schema 列"，若 ALTER ADD
+      // 不补齐，新列在旧行上就是**键不存在**：内存里 `{id,name}`、而同一行经
+      // 落盘再读回（KVStore/Aria 的恢复路径会走 validateRow）变成
+      // `{id,name,phone:null}` —— 同一行的形状取决于"是否重启过"。
+      // 显式物化后，内存视图与持久化视图一致。
+      const addTable = this.tables.get(tableName)!;
+      for (const row of addTable.values()) {
+        if (!(column.name in row)) row[column.name] = null;
+      }
       return;
     }
     if (!schema.columns[column.name]) {

src/query/ast.ts

@@ -158,6 +158,17 @@ export interface SelectUnionStatement {
   right: SelectStatement | SelectUnionStatement;
   /** UNION ALL 不去重 */
   all?: boolean;
+  /**
+   * v0.8.0（A26）：复合查询**整体**的 ORDER BY / LIMIT / OFFSET。
+   *
+   * SQL 标准里这三者作用于整个 UNION 结果，而不是最后一个 SELECT。
+   * 此前 AST 没有这三个字段，parser 把它们挂在了 UNION 右侧的 SELECT 上 ——
+   * 于是 `A UNION B ORDER BY id DESC` 只对 B 排序、`... LIMIT 3` 只截断 B
+   * （实测 `SELECT id FROM t UNION SELECT id FROM t LIMIT 3` 返回 4 行）。
+   */
+  orderBy?: OrderBy[];
+  limit?: number;
+  offset?: number;
 }
 
 // ---------------------------------------------------------------------------

src/sql/parser.ts

@@ -401,6 +401,7 @@ export class Parser {
     const right = this.parseSelect();
 
     const unionStmt: SelectUnionStatement = { type: 'SELECT_UNION', left, right, all: all || undefined };
+    this.adoptTrailingClauses(unionStmt, right);
     // 链式 UNION
     if (this.curTokenIs(TokenType.UNION)) {
       return this.parseUnionChain(unionStmt);
@@ -418,12 +419,46 @@ export class Parser {
     }
     const right = this.parseSelect();
     const unionStmt: SelectUnionStatement = { type: 'SELECT_UNION', left, right, all: all || undefined };
+    this.adoptTrailingClauses(unionStmt, right);
     if (this.curTokenIs(TokenType.UNION)) {
       return this.parseUnionChain(unionStmt);
     }
     return unionStmt;
   }
 
+  /**
+   * v0.8.0（A26）：把"最后一个 SELECT 上的 ORDER BY / LIMIT / OFFSET"上移到
+   * 复合查询节点，并把这些子句从该 SELECT 上**移除**。
+   *
+   * 为什么必须"移动"而不是"复制"：
+   *   - 语法上它们写在最后一个 SELECT 之后，但 SQL 语义作用于整个 UNION
+   *     （`A UNION B LIMIT 3` 是"合并去重后取前 3 行"，不是"B 取前 3 行"）；
+   *   - 若只复制不移除，LIMIT 会**应用两次** —— 正是 A5/A6 那类"两处都生效"
+   *     缺陷的同一个坑（B 先被截断，再对合并结果截断，结果可能少行）。
+   *
+   * 由于 `parseSelect` 无法预知后面有没有 UNION（它在返回后才知道），
+   * 只能先让它照常解析、发现 UNION 时再回收 —— 这比"预读 UNION"简单且无回溯。
+   */
+  private adoptTrailingClauses(
+    unionStmt: SelectUnionStatement,
+    right: SelectStatement | SelectUnionStatement,
+  ): void {
+    // 链式 UNION 时右侧可能已是 UNION 节点，其尾部子句在创建时已上移
+    if (right.type !== 'SELECT') return;
+    if (right.orderBy) {
+      unionStmt.orderBy = right.orderBy;
+      delete right.orderBy;
+    }
+    if (right.limit !== undefined) {
+      unionStmt.limit = right.limit;
+      delete right.limit;
+    }
+    if (right.offset !== undefined) {
+      unionStmt.offset = right.offset;
+      delete right.offset;
+    }
+  }
+
   /** 解析 JOIN 子句列表 */
   private parseJoinClauses(): import('../query/ast').JoinClause[] {
     const joins: import('../query/ast').JoinClause[] = [];

src/table/validation.ts

@@ -131,9 +131,19 @@ export function compileValidator(schema: TableSchema): RowValidator {
 
       assertNotNullConstraints(table, colName, colDef, value);
       if (value !== undefined && value !== null) {
+        assertJsonSafeNumber(table, colName, value);
         checkFieldType(table, colName, colDef.type, value, colDef);
       }
-      if (value !== undefined) validated[colName] = value;
+      // v0.8.0（B-1）：缺列且无 default → 显式写入 NULL，**不能省略键**。
+      //
+      // 此前 `if (value !== undefined) validated[colName] = value;` 会把这个列整个
+      // 从行里删掉，于是存储行只含"有值的列"，行形状取决于写入方式：
+      //   INSERT INTO t (id, g) VALUES ('9','z')   -- 行里没有 n 键
+      //   SELECT id, g, n FROM t WHERE id = '9'    -- 抛 COLUMN_NOT_FOUND: n
+      // 而 `SELECT * FROM t` 却能正常返回（少一列而已）—— 同一行"有没有 n 列"
+      // 在读路径上给出相反结论。SQL 语义中"未提供值"就是 NULL，故统一补 null：
+      // 行始终包含全部 schema 列，投影/排序/三值比较才有统一前提。
+      validated[colName] = value === undefined ? null : value;
     }
     return validated;
   }
@@ -158,6 +168,7 @@ export function compileValidator(schema: TableSchema): RowValidator {
       if (value === undefined) continue;
       assertNotNullConstraints(table, colName, colDef, value);
       if (value !== null) {
+        assertJsonSafeNumber(table, colName, value);
         checkFieldType(table, colName, colDef.type, value, colDef);
       }
       values[colName] = value;
@@ -172,6 +183,33 @@ export function compileValidator(schema: TableSchema): RowValidator {
 //  共享约束
 // ---------------------------------------------------------------------------
 
+/**
+ * 检查字段类型（含约束校验）。
+ *
+ * v0.8.0（B-1）：在 `checkFieldType`（table/schema.ts）之外**额外**拒绝
+ * `NaN` 与 `±Infinity`。为什么必须有这一层：
+ *   - JSON 无法表示它们 —— `JSON.stringify({ v: NaN })` 得到 `{"v":null}`，
+ *     于是 `INSERT ... VALUES (NaN)` 在内存引擎里是 NaN，落盘再读回来变成 null；
+ *     同一个库在"写后立即查"与"重启后查"得到不同结果，且没有任何提示。
+ *   - KVStore / Aria 的持久化路径都是 JSON，因此这是**所有**磁盘引擎的共性问题。
+ *   - 用户能构造出 NaN：`Number('abc')`、`0/0`、`parseFloat('x')` 等，
+ *     经由参数绑定进入写入路径。
+ * 显式拒绝（`VALIDATION_ERROR`）让问题在写入时暴露，而不是变成读出来的 null。
+ */
+function assertJsonSafeNumber(
+  table: string,
+  colName: string,
+  value: unknown,
+): void {
+  if (typeof value !== 'number') return;
+  if (Number.isFinite(value)) return;
+  throw new DatabaseError(
+    `Column "${colName}" in table "${table}" cannot store ${Number.isNaN(value) ? 'NaN' : String(value)}:`
+    + ' it is not representable in JSON and would be silently read back as null',
+    'VALIDATION_ERROR',
+  );
+}
+
 /**
  * NOT NULL 类约束。
  *