bug: #308 以降 歌詞解決が直列全探索で極端に遅く、有名曲を間欠的に取りこぼす

[GeneralD]

#308（確信度ベースのメタデータ+歌詞解決）以降、実運用で 2 つの体感が起きている。両者は独立の症状に見えるが、**どちらも「全候補 × 全ソース × 全 Tier を直列で試す」という #308 のと #318 の per-call ephemeral session が噛み合った**で、相互にさせ合っている。

症状 A — 未キャッシュ曲の歌詞が極端に遅い

以前よりも、キャッシュされていない曲のが出るまでがずっと遅くなった。曲の中盤くらいになってやっとされることもある。

症状 B — 有名曲を間欠的に取りこぼす

タイトル/アーティストはカバー曲でも原曲のものがきちんと取れていて一見が高そうに見えるのに、見つからないはずのない曲の歌詞を間欠的に取りこぼすようになった。

原因

原因 1（症状 A）— メタデータ・歌詞解決の全経路が直列全探索

#308 が「LLM が当たっても短絡せず全ソースを試す／全候補を全 Tier で試す」に倒したため、未キャッシュ曲では以下がすべて 直列 await で積み上がる。

段階	直列/並列	最悪時間
debounce	固定	0.3s
MetadataRepositoryImpl.resolve() LLM	直列	60s（#318 timeout）
同 MusicBrainz（内部 2 クエリ直列）	直列	10s × 2 = 20s
同 Regex	直列（ローカル）	~0s
fetchLyrics Tier A（LRCLIB get）	直列 × N 候補	10s × N
同 Tier B（LRCLIB search）	直列 × N 候補	10s × N
合計（候補 N=10, Tier C 未）		約 280 秒（≈4 分 40 秒）

async let / withThrowingTaskGroup は使われておらず、MetadataRepositoryImpl.resolve() の 3 ソースも、fetchLyrics の候補ループもすべて逐次 await。候補数は区切り記号の多いや MusicBrainz の複数レコーディングで 5〜15 件になり得るため、10s × N × 2 Tier がそのまま効く。「曲の中盤でやっと」という体感（一般的なポップスで 3〜5 分）はこの見積もりレンジとする。

原因 2（症状 B）— Tier A だけがバリデーション無しでキャッシュ書き込みする非

fetchLyrics(candidates:) は冒頭のキャッシュ read で 全行を無で再バリデートする（#308 が pre-#308 の poisoned row を握りつぶすために入れたもの）。ところが書き込み側は非で、Tier A（tierAExactMatch）だけが LyricsMatchValidator を通さずに store() する（Tier B/C は書き込みに必ず isValid を通す）。

さらに LyricsMatchValidator.normalized は text.lowercased().filter { $0.isLetter || $0.isNumber } で**空白・記号を全して**する方式のため、括弧書き・付記を特別扱いしない。短いタイトルに定型サフィックスが付くと簡単に 0.6 を割る。

candidate  "Yesterday"                 → "yesterday"                (9)
LRCLIB     "Yesterday - Remastered 2009" → "yesterdayremastered2009" (24)
Levenshtein=15  類似度 = 1 - 15/24 = 0.375  → 0.6 未満で invalid

有名曲ほどリマスター/ライブ/別バージョンのカタを持つため、無名曲より有名曲の方が引っかかりやすい非性を持つ。

false negative のループ:

1. 有名曲を初回再生 → Tier A が LRCLIB /api/get にヒットし、無のまま閾値割れの行をキャッシュ書き込み。歌詞は直接 return されるので初回は正しくされる（title/artist も原曲寄りで「精度が高そうに見える」）。
2. 2 回目以降の再生 → read ループで行がヒットするが validator.isValid が false → continue でキャッシュを握りつぶし、ライブ再取得（原因 1）に落ちる。
3. ライブ再取得は毎回 10s タイムアウトのネットワーク。LRCLIB の的な 5xx / タイムアウト / レートに晒される。Tier C は fallback_command 未なら即 nil で網にならない。
4. 全 Tier が nil → fetchLyrics が nil → は .notFound（歌詞なし）。

つまり症状 B の実害は、原因 1 の「遅い直列全探索」があるからこそ、キャッシュを握りつぶすたびにネットワーク不調に晒されて化する。両者は #308 から派生し、相互にしている。

— と歌詞検索の経路

用タイトル/アーティストは常に candidates.first（＝LLM 補正済みのな名前）を使う一方、歌詞取得はフル候補配列を別で処理する。これ自体は false negative の直接原因ではないが、「はなのに歌詞が出ない」という体感のを作っている。

1. LLM（[ai]）をした状態で lyra daemon を。
2. キャッシュに無い曲（特にリマスター/ライブ表記のある有名曲）をする。
3. 症状 A: 歌詞が出るまで数十秒〜数分待たされる（曲のでやっと）。
4. 曲をもう一度再生する。
5. 症状 B: 初回は出たのに、2 回目以降は的に「歌詞なし」になる。

期待する

• 未キャッシュ曲でも、候補群を**探索**し「最初にヒットしたものを、他はキャンセル」することで、最悪でも「最も遅い 1 回のタイムアウト」（数秒〜十数秒）でされる。
• 一度キャッシュに乗った有名曲は、read 時の再バリデーションで握りつぶされず、再生のたびにしてされる。

実際の

• 未キャッシュ曲は直列全で最悪 4〜5 分待たされる。
• Tier A が閾値割れの行を書くと、2 回目以降の再生で毎回キャッシュが握りつぶされ、ネットワークのたびに歌詞なしへする。

該当箇所

• Sources/MetadataRepository/MetadataRepositoryImpl.swift:15-22 — LLM → MusicBrainz → Regex を async let/TaskGroup 無しで await
• Sources/MetadataDataSource/MusicBrainzMetadataDataSourceImpl.swift:35-45 — 2 クエリを直列ループ、両方で 20s
• Sources/LyricsRepository/LyricsRepositoryImpl.swift:39-47 — キャッシュ read が全直列 + 全行を無条件で再バリデート
• Sources/LyricsRepository/LyricsRepositoryImpl.swift:64-74 — Tier A が validator.isValid を通さず store()（Tier B: 88 行目 / Tier C: 106 行目は通している）
• Sources/LyricsRepository/LyricsMatchValidator.swift:28-30 — normalized が空白・記号を全して（付記に弱い）／閾値 0.6（4 行目）
• Sources/ScopedAPISession/ScopedAPISession.swift:32-38 — per-call ephemeral session（TCP/TLS 再利用不可、直列呼び出しとが悪い）
• Sources/TrackInteractor/TrackInteractorImpl.swift:182,188-191,200-203 — メタデータ → 歌詞解決が直列、は candidates.first を使用

案

原因 1（）

• MetadataRepositoryImpl.resolve() の 3 ソースを async let で化。
• MusicBrainzMetadataDataSourceImpl.resolve() の 2 クエリを化。
• fetchLyrics の候補探索を withThrowingTaskGroup で並列化し、最初に validate したものをして他をキャンセル（Tier 度は保ちたいので、Tier 内で候補を並列 → Tier 間はというが候補）。
• タイムアウトの見直し（LRCLIB/MB の 10s は直列前提だと重い）。

原因 2（false negative）

• Tier A にも書き込みに validator.isValid を通す（非の）。または read 時の再バリデーションを「pre-自動・確信度ベースのメタデータ+歌詞解決サイクル #308 判定用のバージョンマーカーを持つ行」だけに限定し、post-自動・確信度ベースのメタデータ+歌詞解決サイクル #308 に書かれた行は書き込み時点で保証済みとしてする。
• LyricsMatchValidator.normalized の付記を上げる（(Remastered 2009) / - Live などのサフィックス、あるいはトークンベース度）。
• Tier A の書き込み行が validator 基準を満たすことを保証する不変条件を（現状 LyricsRepositoryTests に該当が無く、これがをできなかった）。

• #308 — 確信度ベースのメタデータ+歌詞解決（本 issue のの）
• #318 — 長時間で歌詞が出なくなる（per-call ephemeral session を）