chore(docs): 删除 v0.7.4 审计与 v0.7.5 计划共 4 个 md 文档

删除：
- AUDIT-aria-lsm-v0.7.4.md（50KB）
- AUDIT-query-layer-v0.7.4.md（39KB）
- AUDIT-storage-engines-v0.7.4.md（39KB）
- PLAN-v0.7.5.md（98KB，含附录 G/H/I）

删除前先清除引用面，避免留下断链（共 18 处）：
- 源码注释 7 处（change-notifier / kvstore index / column-value / expression /
  sql-compare / where-matcher / validation）：保留设计意图，引用改为"v0.8.0 审计根因 N"
- 测试注释 9 处（opfs.spec / aria-opfs-backend / faulty-backend / storage-harness /
  v080-b6 / v080-kvstore / v080-query-layer / v080-sql-three-valued /
  v080-unified-validation / parser）：同上
- CHANGELOG 3 处：改为不依赖已删除文档的自洽表述（B-6 交付物见各条；门禁订正三处
  按内容重写），并把变异数量同步为 42
- 校验：三个 md 之间无断链；仓库内已无 PLAN-v0.7.5/AUDIT-* 的任何引用
  （git 历史仍可追溯，需要时可 `git show <commit>:PLAN-v0.7.5.md` 找回）

验证：93 套件 / 1985 用例全绿；覆盖率 90.59 / 82.61 / 94.14 / 93.50（阈值 90/82/94/93）；
e2e 14/14；lint + 两份 tsc 干净；dist 已重建（注释只影响非压缩产物，min 产物
251,731 B / gzip 63,431 B 不变）。

说明：审查记录的核心内容仍在 CHANGELOG.md（"全量回归审查"与"现场失败修复"两节），
随 PLAN 一起删除的是附录 G/H/I 的详细表格（门禁逐条验收、交付物清单、未修复项表）。

dist/metona-sqlark.esm.js

@@ -49,7 +49,7 @@ const VERSION = '0.8.0';
  * @module engine/change-notifier
  *
  * ============================================================================
- * 为什么需要它（PLAN-v0.7.5.md A9）
+ * 为什么需要它（v0.8.0 审计 A9）
  * ============================================================================
  * `db.subscribe(table, fn)` 此前对**本地写入永不触发**：全库只有一处调用 `emit`，
  * 而那一处在 BroadcastChannel 收到**其它标签页**消息时才执行。于是：
@@ -398,7 +398,7 @@ function cloneRowFallback(value) {
  * @module query/sql-compare
  *
  * ============================================================================
- * 为什么需要它（PLAN-v0.7.5.md 根因 2 / PB-2）
+ * 为什么需要它（v0.8.0 审计根因 2 / PB-2）
  * ============================================================================
  * 此前项目里并存**五套**值相等语义：
  *   1. `where-matcher` 的 `===`
@@ -637,7 +637,7 @@ function sqlIn(value, list) {
  * @module query/where-matcher
  *
  * ============================================================================
- * v0.8.0 根治：为什么这里只剩**一个**递归求值器（PLAN-v0.7.5.md 根因 1/7、PB-2）
+ * v0.8.0 根治：为什么这里只剩**一个**递归求值器（v0.8.0 审计根因 1/7、PB-2）
  * ============================================================================
  * 历史上有两套并存的实现：
  *   - `matchWhere` —— 布尔版（自己的 `$and/$or/$not` 分支 + `matchField`）；
@@ -1074,7 +1074,7 @@ function unquoteIdentifier$1(text) {
  * @module table/validation
  *
  * ============================================================================
- * 为什么必须合并（PLAN-v0.7.5.md 根因 1：关系语义在引擎间重复实现）
+ * 为什么必须合并（v0.8.0 审计根因 1：关系语义在引擎间重复实现）
  * ============================================================================
  * 修复前项目里存在**三份**行校验实现，覆盖范围各不相同：
  *
@@ -3346,7 +3346,7 @@ class KVStore {
      * 实际数据已经落盘 —— 报错与事实相反，属于最有害的一类不一致
      * （调用方据此重试会写入两次，或据"失败"丢弃业务状态）。
      *
-     * 现在的语义（与 PLAN-v0.7.5.md 的 B-6 止血方案一致）：
+     * 现在的语义（与 B-6 止血方案一致）：
      *   - 已确认的写入**不得**因为后台失败而报错；
      *   - 失败被记录为 `lastBackgroundError`，由**下一次** `checkpoint()`
      *     显式报告（那是用户主动要求把数据压实到快照的时机，此时失败是真实问题）；
@@ -15092,7 +15092,7 @@ function parseWhereCondition(sql) {
  * @module query/column-value
  *
  * ============================================================================
- * 为什么必须只有一个实现（PLAN-v0.7.5.md 根因 1）
+ * 为什么必须只有一个实现（v0.8.0 审计根因 1）
  * ============================================================================
  * "从一行里按名字取一列"曾是四处各写一份的实现，规则各不相同：
  *
@@ -15163,7 +15163,7 @@ function resolveColumnValue(row, reference, opts) {
  * @module query/expression
  *
  * ============================================================================
- * 为什么必须换掉原实现（PLAN-v0.7.5.md 根因 3：字符串化 AST 表达式列）
+ * 为什么必须换掉原实现（v0.8.0 审计根因 3：字符串化 AST 表达式列）
  * ============================================================================
  * 原 `parseCaseExpression` 用**正则**在原始 SQL 文本上切分 WHEN/THEN/ELSE：
  *