fix(site/v0.8.0): 站点版本同步 + 现场失败修复（file:// 打不开 OPFS 的可操作错误）

用户报告"站点演示失败了"，实测复现并定位根因：

- 现象：直接双击 site/demo.html（file://）→ 点「🌲 Aria」→
  "❌ 数据库初始化失败: Failed to open AriaEngine database "demo""（Memory 正常）。
- 根因：file:// 属不透明来源，Chromium 拒绝 navigator.storage.getDirectory()
  并抛 SecurityError；此时 isSecureContext 仍为 true、API 也存在，无法提前探测。
  引擎把它包成 ARIA_OPEN_ERROR 时丢掉了底层错误 → 消息对用户不可操作。
- 修复：OPFSBackend.open() 显式检查并抛 ARIA_OPFS_UNAVAILABLE，消息给出两条出路
  （用 http(s) 打开 / 改用 mode:'memory'），原始 SecurityError 挂 cause；
  site/demo.html 额外用中文说明"为什么失败 + 怎么修"。

顺带修掉一个更普遍的问题：DatabaseError 的第三个参数只进 details，err.cause
恒为 undefined，而文档/注释多处写"底层错误作为 cause 保留"。现在两者都成立
（details 语义不变；cause 声明为公开字段并接入标准错误链）。

站点版本同步：demo.html（title / 状态栏 / SQL 预置脚本 / console 日志）与
benchmark.html（title）此前仍是 v0.7.4（日志甚至是 v0.4.2）→ 统一 v0.8.0；
docs.html 的 AriaEngine 版本演进列表补上 v0.8.0 条目、错误码表补
ARIA_OPFS_UNAVAILABLE；README 补"OPFS 需要 http(s) 页面"的浏览器兼容说明。

回归与门禁：tests/engine/aria-opfs-unavailable.test.ts（5 项，含正常环境正控）；
变异 R19 / R20 均被拦住（总计 42/42）；93 套件 / 1985 用例；覆盖率
90.59 / 82.61 / 94.14 / 93.50（阈值 90/82/94/93）；e2e 14/14；lint + 两份 tsc 干净；
dist 重建（251,731 B / gzip 63,431 B）并已同步全部体积宣称。

site/docs.html

@@ -140,7 +140,7 @@ npm install @metona-team/metona-sqlark</pre>
 <table>
   <tr><th>文件</th><th>格式</th><th>用途</th></tr>
   <tr><td><code>metona-sqlark.js</code></td><td>UMD</td><td>浏览器开发版（含 sourcemap）</td></tr>
-  <tr><td><code>metona-sqlark.min.js</code></td><td>UMD (minified)</td><td>生产环境（实测 251,109 字节 / gzip 63,145 字节，含全部引擎与 SQL 层）</td></tr>
+  <tr><td><code>metona-sqlark.min.js</code></td><td>UMD (minified)</td><td>生产环境（实测 251,731 字节 / gzip 63,431 字节，含全部引擎与 SQL 层）</td></tr>
   <tr><td><code>metona-sqlark.esm.js</code></td><td>ES Module</td><td>现代打包工具 / 浏览器 ESM</td></tr>
   <tr><td><code>metona-sqlark.cjs</code></td><td>CommonJS</td><td>Node.js require()</td></tr>
   <tr><td><code>metona-sqlark.d.ts</code></td><td>TypeScript 声明</td><td>类型提示</td></tr>
@@ -815,6 +815,7 @@ db.<span class="f">broadcastChange</span>(<span class="s">'users'</span>);</pre>
 <strong>v0.7.2 语句级原子性 / 事务 DDL / 约束硬化</strong> — UPDATE 语句级两阶段原子（多行匹配第 N 行失败整句不执行 + 批内唯一互查）· 事务内 DDL 显式拒绝（四引擎对齐）· SET NULL 级联绕过 required 约束整体拒绝 · 参数绑定注释感知（注释中 `?`/引号不参与绑定）· 未闭合字符串显式 PARSE_ERROR · 未知 where 操作符抛 QUERY_ERROR（此前静默全匹配）· update undefined 语义化（保留旧值）· Hybrid write-through 失败补偿（磁盘失败自动重载内存对齐）。<br>
 <strong>v0.7.3 深度审计第六阶段：INSERT 原子 / 索引一致性 / 边界窗口</strong> — INSERT 语句级两阶段原子（三引擎 + Aria PK 批内重复，此前部分提交）· 索引列 IS NULL 恒空修复（Memory/KVStore/Hybrid，对齐 Aria）· delete RESTRICT 预检不再破坏索引 · queryStream 子查询静默空结果修复（$subquery/$exists/$col 回退物化）· ALTER DROP 索引列残留清理 · CREATE UNIQUE INDEX 存量重复数据校验（失败原子回滚）· <code>SELECT *, col AS alias</code> 解析与投影 · WAL BEGIN/ROLLBACK 写失败窗口修复（事务不泄漏/数据不复活）· aria $in 批级预加载（消除逐值 drainChain 性能悬崖）· 多条件 AND 等值下推（索引真正生效，EXPLAIN 同步）· ANALYZE 统计含二级索引 · React/Vue hooks 生命周期修复（config 变更重建 / 卸载关闭）· 迁移无主键旧库兜底 · 1256 测试 75 套件 · 90.0% 行覆盖率。<br>
 <strong>v0.7.4 深度审计第七阶段：写语句子查询 / 约束硬化 / 真惰性流式</strong> — UPDATE/DELETE WHERE 子查询正确执行（四引擎，此前静默 0 行；关联引用显式 NOT_SUPPORTED；EXPLAIN 估算同步修复）· 主键 NULL/undefined 强制拒绝（SQL 语义 PK 隐含 NOT NULL，此前静默生成 "null"/"undefined" 主键）· DROP INDEX 保留建表 UNIQUE 约束（对齐 SQLite：需重建表解除；仅 CREATE UNIQUE INDEX 添加的可随索引删除）· GROUP BY / DISTINCT / UNION 键类型安全编码（null 与 'null' 字符串不再合并）· UPDATE 未知列显式 COLUMN_NOT_FOUND（此前脏列写入存储行）· queryStream 多语句显式 PARSE_ERROR（此前静默忽略后续语句）· KVStore 后台错误跨 reopen 清理 + Hybrid beginTransaction 失败补偿回滚 · <strong>Aria findStream 真惰性</strong>（MergeIterator 迭代器化 + SSTable/MemTable 生成器扫描，limit 提前终止，大表流式内存 O(1)——此前内部 drain 全量物化）· REINDEX 单次全表扫描重建全部索引列（此前每列一次全扫描）· RB-Tree 删除双黑修复边界 + LSM 死代码清理 · 1304 测试 76 套件 · 90.1% 行覆盖率。</p>
+<strong>v0.8.0 根治性迭代：统一语义 / 消灭复发结构 / 验证基础设施</strong> — 三份行校验实现收敛为唯一 choke point（未知列/NaN 显式拒绝）· 唯一值比较与编码原语 · SQL 与 TABLE API 单管线（QueryBuilder 只产 AST）· CASE 表达式改 token 流递归下降 · 输出列序号与分隔标识符 · <strong>`__aria_manifest_&lt;generation&gt;` 单一提交点</strong>（页面水位 + SSTable 元数据 + 表结构 + WAL 水位 + 冻结表意图一次原子提交；头部/载荷双 CRC、先写后验、保留两代；顺序固定为<strong>数据落盘 → manifest 提交 → 才允许截断 WAL / 删除旧文件</strong>）· 元数据损坏不再静默空库（`ARIA_MANIFEST_CORRUPT` / `ARIA_LEGACY_META_CORRUPT`）· WAL LSN 全库单调 + 按水位删除分片 + 空洞与记录级损坏<strong>如实上报</strong>（`ARIA_WAL_GAP` / `droppedWALRecords`）· LSM 冻结表一等状态、compaction 不再摘整层、底部层原地合并回收墓碑、按层 `compacting`、退休表 + 读者 epoch · 读路径"快照 + 结构版本乐观重试"（删除全部 prefetch 依赖）· checkpoint 不等 compaction（根治 "8~11s 悬崖"）· 介质读故障与"文件不存在"分离（`ARIA_SSTABLE_READ_FAILED`，不误删元数据）· 恢复报告 `getRecoveryReport()` · 覆盖率门禁 + 变异验证（40 项）成为标准做法 ✅ v0.8.0
 
 <h3>存储模式对比</h3>
 <table>
@@ -932,7 +933,8 @@ db.<span class="f">broadcastChange</span>(<span class="s">'users'</span>);</pre>
   <tr><td><code>ARIA_MANIFEST_NOT_LOADED</code></td><td>未 <code>load()</code> 就提交 manifest：拒绝写坏介质 🆕 v0.8.0</td></tr>
   <tr><td><code>ARIA_SSTABLE_SAVE_CONTRACT</code></td><td>存储实现违反 <code>save()</code> 契约（既不抛错也不返回结果）：不把"写调用返回了"当成落盘成功 🆕 v0.8.0</td></tr>
   <tr><td><code>ARIA_DB_NOT_OPEN</code></td><td>在 <code>open()</code> 之前使用 Aria 存储层（如加密后端） 🆕 v0.8.0</td></tr>
-  <tr><td><code>ARIA_OPEN_ERROR</code></td><td>AriaEngine 打开失败（底层错误作为 cause 保留） 🆕 v0.8.0</td></tr>
+  <tr><td><code>ARIA_OPEN_ERROR</code></td><td>AriaEngine 打开失败（底层错误保留在 <code>err.details</code> 与标准 <code>err.cause</code> 上，便于定位根因） 🆕 v0.8.0</td></tr>
+  <tr><td><code>ARIA_OPFS_UNAVAILABLE</code></td><td>OPFS 在当前环境不可用（如 <code>file://</code> 页面被 Chromium 禁止访问 OPFS）：错误信息给出可操作建议（改用 http(s) 或 <code>mode:'memory'</code>） 🆕 v0.8.0</td></tr>
   <tr><td><code>DB_NOT_OPEN</code></td><td>数据库未打开（KVStoreEngine 操作前未 <code>open()</code>）</td></tr>
   <tr><td><code>KV_SCHEMA_ERROR</code></td><td>KVStore 中的表结构记录损坏</td></tr>
   <tr><td><code>KV_LOG_ERROR</code> / <code>KV_BACKGROUND_ERROR</code></td><td>KVStore 日志写入失败 / 后台刷盘失败</td></tr>