[embed-on-write 調査] WASM 側 embedding の実現性 ── コードは通る、モデル 512MB が壁

今日の流れと次セッションの再開起点。起点 vision = `n_01KSPRQVEVXDK8538DT2WV5D93`(「embedding も agent も軽い仕事なら wasm で」)。

## 出荷済み
- **C = embedding 近傍の性質タグ提案**(thread 詳細でワンタップ追加、cosine は DuckDB-WASM で完結)/ PR #296。
- **`/embeddings.json` proxy 漏れを修正** / PR #303。CF `run_worker_first` と vite proxy の両方から root の embeddings マニフェストが漏れ(#283 fallout)、prod/local とも embedding が無言で死んでいた(related-posts も巻き添え)。両方に追加して復活。

## 方向 = embed-on-write(C→A→B→D の D 核)
- **動機**:embedding が外部 producer 任せで stale(prod は 5 月分 374 件のみ、6 月以降は未 embed)。「そのための wasm」── **投稿時にブラウザ(WASM)が本文を embed → import** すれば外部 producer も cron も要らず stale が消える。import-only ポリシーとも整合(計算する人が外部ツール→client に移るだけ、server は計算しない)。
- **書き込み経路はタダ**:`mcp.ts` に `import_embedding` ラッパ 1 個。embedder = **Rust→WASM(model2vec_rs そのまま)**を選択(producer と同コード=fidelity がタダ)。

## Phase 0 spike 結果
- ✅ **model2vec-rs の `wasm` feature**(local-only + tokenizers/unstable_wasm)が **wasm32-unknown-unknown で素直にコンパイル**(27s、.wasm = 3.3MB)。`from_bytes(tokenizer,model,config)` あり。**プランビングは実証済み**。
- ⚠️ **壁 = モデルの重み**。`potion-multilingual-128M` の `model.safetensors` = **512MB**(128M params f32)+ tokenizer.json 18.6MB。ブラウザに配るのは非現実的。ボトルネックはコードでなく**モデルサイズ**。
- fidelity(onig vs unstable_wasm)は未検証 ── モデルを選び直せば producer も同モデルに揃え空間一致がタダになるので棚上げ。

## 残る判断(再開ポイント)
ブラウザに載る多言語 static モデルにして **corpus を再 embed**(= backfill 兼用、fidelity も自動解決)。トレードオフ = 小型化 = 品質低下。選択肢:
- **int8 量子化** ≈ 128MB(まだ重い)
- **次元削減 + 量子化**で数十 MB(品質↓)
- **小さい多言語 model2vec を選ぶ/蒸留**
- **方針再考**:100MB+ を落とす価値があるか ── producer 自動実行(cron)の方が妥当な可能性(鮮度 vs DL 重量)

## スコープ外 follow-up
暗号化 post の embed(平文由来ベクトルの可視性設計)/ 編集時 re-embed / 6月分 backfill。