desktop/browser v1: 新規タブ / マルチタブ UI を再有効化 (WebContentsView 移行後)

[MocA-Love]

経緯

PR #371 で v1 <webview> ベースのマルチタブ UI をユーザーから見えないよう非表示にした。理由は Electron <webview> の native GuestView compositor が CSS z-index / pointer-events / opacity を尊重しないため、複数 webview が 1 画面にある状態で以下が不安定だったため:

• 手動でタブを切り替えても描画が最初のタブのまま
• URL 入力欄の履歴候補クリックが webview に吸われる
• スクロールできない / 右クリックメニューが出ない
• 戻る / 進むが時々効かない
• 描画のゴースト残像

詳細は #377 (WebContentsView 移行) を参照。

現状

• ユーザー向け UI: タブバー + overflow menu の "New Tab" を非表示
• 内部コード: secondaryTabRegistry / BrowserTabBar / onCreateTabRequested / tab activation bridge は温存
• MCP (chrome-devtools-mcp / browser-use): Target.createTarget / target="_blank" 経由での secondary tab 生成は内部的には動作。ただしユーザーからは見えない

該当箇所

• apps/desktop/src/renderer/screens/main/components/WorkspaceView/ContentView/TabsContent/TabView/BrowserPane/BrowserPane.tsx の {false && <BrowserTabBar ... />}
• apps/desktop/src/renderer/screens/main/components/WorkspaceView/ContentView/TabsContent/TabView/BrowserPane/components/BrowserToolbar/components/BrowserOverflowMenu/BrowserOverflowMenu.tsx の "New Tab" コメントアウト部

やること

1. 前提: desktop/browser: <webview> から WebContentsView へ移行 (v3) #377 (WebContentsView v3 移行) で parity まで達成
2. v3 が default になった後、v1 側の multi-tab UI コードを撤去 (secondaryTabRegistry / BrowserTabBar 等)
3. OR v1 <webview> を残すなら、v3 で得られた知見で UI を再有効化 (現実的には v1 の根本問題は解決できないので 2 が本命)

備考

• MCP 経由のタブ生成は現状でも動くので、LLM にブラウザを操作させる用途は阻害しない
• v3 移行が完了する前に v1 のマルチタブ UI を「無理に」戻すのは非推奨 (同じ不安定性を再現するだけ)