feat(t73): PDF 抽取器接上 PDFium-via-wazero——leo 裁定的引擎，實測通過

⭐ 決定性實測：Chrome headless 列印的中文 PDF 完整抽出
   「船舶維修合約書／第一條 維修費用為新台幣 350,000 元整／2026 年 8 月 15 日」
   ——這正是 pdf-extraction-options.md §3 實測「純 Go 套件會整段亂碼」的那種檔，
   也是客戶最常丟的（瀏覽器列印）。選 PDFium 的理由至此坐實。

用戶不必裝任何東西（回答 leo「我的用戶可能不會自己裝 Python 環境」）：
pdfium.wasm 由 wazero(純 Go WASM runtime)在本行程跑，embed 進執行檔。
實測 CGO_ENABLED=0 GOOS=windows 交叉編譯一行成功 → PE32+ executable x86-64，
證實「無 CGo」承諾為真，不加重 t72 負擔。

體積實測(有實際呼叫路徑，避開今天記過的 dead-code 陷阱)：
  mac 14.53MB / windows 15.15MB(strip 後)
  leo 定調「全運作在客戶電腦上，肥一點喘一點也沒事」

設計決定：
- lazy init（sync.Once）——多數資料夾可能一個 PDF 都沒有，不該白付 WASM 啟動的記憶體
- pdfMu 互斥——pool 單 worker，別依賴「scan 是循序」這個假設
- 單頁失敗不放棄整份，但留「（第 N 頁讀取失敗）」痕跡
- 抽不出字 → ErrNoText（掃描件；PDFium 不做 OCR），絕不靜默送空內容

測試 4/4：Chrome PDF 中文正確／無文字回 ErrNoText／壞檔報錯可辨識
（『可能損壞或有密碼保護』）／連續多檔不爆(daemon 長駐會遇到)。

convert.go

@@ -57,7 +57,7 @@ var extractors = map[string]extractor{
 	".docx": extractDocx,
 	".csv":  extractCSV,
 	".xlsx": extractXLSX,
-	// .pdf  → PDFium-via-wazero（下一步接；體積 +10.43MB，實測 15頁/2.2MB=134ms）
+	".pdf":  extractPDF, // PDFium-via-wazero（+10.43MB；用戶不必裝任何東西，見 convert_pdf.go）
 	// .pptx → 同 docx 的 ZIP+XML 路數，數十行，體積幾乎不變
 }