fix(dev): recover Tauri shell after Next/Turbopack crash or stale chunk

[CompleteDotTech]

Problem

After the Coven Cave desktop shell crashes or its Next/Turbopack dev server stops, the surviving Tauri WebView can keep requesting a stale dynamic chunk. The user sees a client-side ChunkLoadError, for example:

Failed to load chunk /_next/static/chunks/src_0wgfj9g._.js
from src/components/chat-settings-view.tsx
Next.js 16.2.9 (Turbopack)

A related failure mode is the native shell remaining open at 127.0.0.1 after its loopback server has exited, displaying ERR_CONNECTION_REFUSED.

This was reproduced in the PR integration worktree after an interrupted scripts/dev-app.sh session. The Tauri window survived while no loopback port was listening. A clean coordinated relaunch restored the app: the server listened on 127.0.0.1:3003, Tauri logged its dev-server origin, and GET / 200 succeeded.

Why this matters

A developer can be left with a visually running desktop app that cannot recover by refreshing, while the original cause is no longer visible. The chunk name implicates a client import but is not evidence that the corresponding feature component caused the crash.

Requested work

1. Upgrade the pinned Next.js patch from 16.2.9 to 16.2.11 in a focused maintenance change, keeping React and Tauri versions unchanged unless a compatibility requirement is discovered.
2. Audit scripts/dev-app.sh and the Tauri dev lifecycle so the shell does not outlive an unavailable loopback server.
3. Define crash recovery behavior:
   • detect an unavailable dev-server origin before/after WebView initialization;
   • show a Cave-owned recovery state or retry/reload path instead of a raw browser ERR_CONNECTION_REFUSED page;
   • avoid stale Turbopack dynamic-chunk references after server restart;
   • ensure wrapper interruption cleans up the owned Next dev server and Tauri process tree.
4. Add focused regression coverage for a server crash/restart while the desktop shell is open.

Reproduction

1. Start the desktop shell with bash scripts/dev-app.sh.
2. Interrupt or otherwise terminate the loopback dev server while allowing the Tauri window to remain open.
3. Navigate to a dynamically loaded settings/chat surface or refresh the existing view.
4. Observe either a ChunkLoadError for an old /_next/static/chunks/ asset or 127.0.0.1 refused to connect.
5. Relaunching the entire server + Tauri pair resolves the symptom.

Acceptance criteria

• Next.js is updated to the reviewed 16.2.11 patch and relevant install/build gates pass.
• A desktop shell never remains silently attached to a dead loopback dev server.
• Crash/restart behavior offers a clear recovery action and succeeds without requiring a manual process-tree hunt.
• A focused test covers a stale-chunk or refused-connection recovery path.
• pnpm lint, targeted tests, and pnpm build pass on Windows.

Context

This is not attributable to PRs #3819, #3820, #3821, #3823, #3825, #3826, #3828, or #3830: none changes src/components/chat-settings-view.tsx.

[CompleteDotTech]

@BunsDev — assigning this for triage. The immediate decision is whether to ship the focused Next.js 16.2.11 patch first, then add dev-shell recovery/cleanup coverage so a Tauri window cannot outlive its loopback server. The issue includes the observed ChunkLoadError, refused-connection state, reproduction, and Windows acceptance criteria.