feat: 为扩展本地查询引入 SQLite + OPFS 读模型

[aurora1112-j]

变更概述

本 PR 在保持 Chrome 扩展形态不变的前提下，引入了基于 SQLite + OPFS 的本地读模型，用于承接查询密集路径；Dexie / IndexedDB 仍然保留为 authoritative write path。

主要改动包括：

• 将 offscreen 收口为存储执行 owner，并在其中启动唯一的 storage worker
• 引入 SQLite + OPFS 读模型，并增加初始化、迁移、校验、回退机制
• 将以下查询路径切为 SQLite-first，失败时回退 Dexie：
  • 文本搜索
  • related conversations
  • Network edges
  • Library 列表过滤 / 时间范围查询
  • topic counts
  • dashboard 统计
  • Explore 的语义上下文检索
• UI 层 StorageApi 保持不变
• 增加 storage engine 状态展示与错误可见性
• 补充 storage foundation spec 与 engineering handoff 文档

验证

已完成：

• pnpm -C frontend build
• 手动 smoke：
  • capture
  • Explore
  • Network

说明

• Dexie / IndexedDB 仍然是主写入链路，SQLite 当前定位为 query read-model
• 本 PR 不包含本地 embedding 生成、不包含 FTS、不包含 sqlite-vec / ANN
• 当前仓库基线上仍存在部分与 @vesti/ui / artifact 相关的 TypeScript 问题，不属于本 PR 的核心存储查询改动范围

当前离线能力边界

本次改动主要提升的是扩展内部的本地存储与查询能力。

已经本地化的部分：

• 会话、消息、批注、topic、summary、weekly report 等数据的本地持久化与读模型同步
• 文本搜索、Library 列表过滤、topic counts、dashboard 统计
• related conversations、Network edges、Explore 语义上下文检索的本地查询与计算

仍然依赖联网或外部模型服务的部分：

• LLM 回答生成
• summary / weekly report 生成
• embedding 生成

也就是说，本 PR 实现的是“查询和检索尽可能本地化”，而不是“整个 Explore / LLM 能力完全离线化”。

后续如果要进一步提升离线能力，优先方向会是：

1. 本地 embedding 生成可选化
2. 再评估 FTS / sqlite-vec / ANN 等更完整的数据库检索方案