CI: add Windows packaged-build smoke test for puppeteer/Chromium resolution

[ystknsh]

Summary

1.0.14-rc-1 の Windows ビルドで puppeteer の同梱 Chromium 解決が壊れていた事故（#1641 相当、release_notes_v1.0.14 にバグ修正として記載）の再発防止として、Windows packaged build を実際にインストール→起動してログを assertion する CI ジョブを追加したい。

通常の yarn test / yarn lint / yarn type-check では Vite/Rolldown のバンドル出力の差異に起因するこの種のバグは検出できないことが確認された（rc-1 までの全 CI は green だった）。

Background

• Vite 7→8（Rollup→Rolldown）移行で CJS/ESM interop の挙動が変わり、bundle 出力での puppeteer.launch 呼び出し形が default インスタンス側から named export スナップショット側に変わっていた
• main.ts のランタイムパッチは default 側だけを差し替えていたため、bundle 経由の launch にパッチが届かず、同梱 Chromium への executablePath 注入が失敗
• 検出は手動 QA のリリース直前にようやく発覚
• rc-2 で修正済み（default + named 両方を patch、加えて env var を puppeteer 読み込み前に確定させる bootstrap モジュール導入）

Proposed CI job

ci-ms.yml の末尾に追加。既存の yarn run publish:ci:win で作られる Squirrel installer を流用し、別ジョブ or 同ジョブ内 step で「インストール → 起動 → ログ assert」を実行する。

検証する 4 項目（起動直後ログ）

```
[PUPPETEER_PATCH] Runtime patch applied: default=true named=true
[PUPPETEER] Bootstrap status: {"kind":"applied", ...}
```

検証する puppeteer 実行時ログ（最小 1 つの md/html ビート生成）

```
[PUPPETEER_PATCH] Intercepting launch with executablePath: ...\chromium\chrome\win64-...\chrome.exe
```

エラーログに以下が出ていないこと:

```
Error: Could not find Chrome
```

トリガー方針の選択肢

検討した案を以下に並べる。採用案はハイブリッド（release/ push 時 + nightly）*。

トリガー	採否	目的 / 採否理由	コスト
release/* ブランチ push 時	✅ 採用	リリース前にブロック（rc-1 のような事故を本番前に検出）。リリース頻度なので追加コスト小	+10〜15 分 / release ビルド
nightly schedule	✅ 採用	main の累積的な依存更新（mulmocast / puppeteer / Electron 等）でこの経路が壊れていないか定常監視。朝の最初の出社時には結果がある	1 日 1 回 × Windows runner 料金
PR ごとに毎回	❌ 不採用	検出は最も早いがコスト過剰（10〜15 分 × PR 数 × Windows runner 料金）。大半の PR は puppeteer/bundle 経路を触らない	—
main への push 時のみ	❌ 不採用	merge 後にしか検出できない＝出戻りが発生する。nightly でカバーできるので冗長	—
release tag push 時のみ	❌ 不採用	tag を打つ＝もう公式リリース。検出しても rollback コストが高い。release/* push 時で十分前倒し検出できる	—
workflow_dispatch（手動）	🟡 併設推奨	採用 2 案に加えて、debug / 単発検証用に手動 trigger も置いておくと便利。コストは実行時のみ	—

PR 単位の代替案として「puppeteer/bundle 経路を触る PR にのみ手動でラベル付与 → ラベル付き PR 限定で起動」は技術的には可能だが、判定漏れで素通りする恐れ + 運用負荷で見送り。

Implementation notes

• 既存の ci-ms.yml の make:ci:win 後に installer を解凍 or silent install
• アプリ起動は CDP 接続を待たずとも、ログファイル (%APPDATA%\\MulmoCast\\mulmocastLog\\app-YYYY-MM-DD.log) を tail / grep でアサート可能
• md ビート生成は API キー不要のテストプロジェクトを用意する必要あり（既存の onboarding プロジェクトを流用 or test/manual_no_api_*.ts 系のパターンに合わせて新規追加）
• nightly は on: schedule: - cron: ... を workflow に追加するだけ
• release ブランチ push 時は on: push: branches: [release/\*] のフィルタを既存ジョブと別ジョブで設定
• workflow_dispatch は on: workflow_dispatch: を同 workflow に追加

Out of scope

• Mac 側の同種テスト（今回の事故は Windows のみで発生したが、将来的に対称性を持たせるかは別検討）
• 完全な E2E（動画書き出しまで）は重すぎるので扱わない、起動 + md 1 ビート生成までで十分

Related

• 1.0.14 リリース時の修正コミット: release/1.0.14-rc-2 ブランチ
• 関連 issue: Windows: splash window loadFile rejects with ERR_FAILED (unhandledRejection in log) #1642（Windows splash ERR_FAILED、別件）