fix(auth): tear down session-keeper WebView after cookie refresh

[mihaimetal]

Summary

• The hidden session-keeper WebView (loads music.youtube.com) was kept open permanently so cookies could be renewed every 20 minutes.
• That leaves a full Music SPA WebContent process in RAM (~300MB+ on macOS), on top of the main tauri://localhost UI process — so a signed-in YTubic can approach a browser Music tab in memory.
• Change: create the keeper only for each refresh cycle, snapshot cookies, then destroy it (including on failure). Next cycle spins a fresh one.
• Periodic timer is unchanged (still every ~20 min, well inside Google’s ~2h extracted-cookie leash).

Why a separate PR (not folded into #41)

• fix(auth): harden macOS Google sign-in, session persistence, and login popup #41 is about macOS sign-in isolation (data stores, wipe, handoff URL).
• This is about keeper lifecycle / RAM and already exists on upstream main with the always-on keeper.
• Easier to review and merge independently; no dependency on fix(auth): harden macOS Google sign-in, session persistence, and login popup #41.

Tradeoffs

• Short cold cost every 20 min (open webview → load → snapshot → close) instead of a permanent ~300MB resident process.
• WebView profile on disk is unchanged; only the live window/process is torn down.

Test plan

• Sign in, wait for first refresh (~20s after launch): Activity Monitor should show a Music/YouTube WebContent process briefly, then it should disappear
• Leave the app running >20 min: library / playback still work (cookies renewed)
• Failed refresh also tears the keeper down (no orphan process)
• Sign-out still cleans up

Related

• Independent of fix(auth): harden macOS Google sign-in, session persistence, and login popup #41 (macOS auth harden)
• Complements fix(auth): harden macOS Google sign-in, session persistence, and login popup #41 if both land

[mihaimetal]

Rebased onto current main after 0.4.0 so this is a clean merge candidate against the release tree.