fix(playback): serve streams via WEB_REMIX only

[mihaimetal]

Summary

• Resolve progressive WebM streams with WEB_REMIX (YouTube Music cookies + SAPISIDHASH): raw Music /player plus youtubei.js decipher.
• Probe googlevideo before registering the stream; headstart / pre-resolved poll for faster start.
• Drop ANDROID_VR / yt-dlp from the hot path (subprocess and client noise removed). yt-dlp plumbing is left in place so it can be re-enabled later if needed.
• Cap logs/stream.log at 2 MiB with rotation to stream.log.1.
• Remove the player UI line under the artist (resolving… / WEB_REMIX / timing).

Why

Cold start with managed PyInstaller yt-dlp was very slow (~12s process spawn). WEB_REMIX with a proper cookie/SAPISIDHASH path gives reliable progressive playback without the multi-client fallback noise (ANDROID_VR LOGIN_REQUIRED, MWEB 403s, etc.).

Design notes for review

• Intentional product choice: WEB_REMIX only for playback right now. Rare resolve misses will fail instead of falling back to yt-dlp until that path is re-enabled.
• CSP allows 'unsafe-eval' so nsig decipher can run in the webview.
• Stream method events still go to stream.log / console for debugging; just not shown under the artist.

Commits

1. Intermediate cold-start work (in-process resolve / progressive path).
2. Final WEB_REMIX-only cleanup (this is the intended end state).

Test plan

• Play uncached tracks on macOS with a logged-in Music account
• Confirm stream.log shows web_remix / probe / music+cookie path (no yt-dlp / android_vr spam)
• Long tracks continue past early buffer
• Release build: YTubic.app runs successfully
• Windows smoke test with the same WEB_REMIX path (same cookie design; not fully verified here)

Related

Independent of the macOS packaging and auth PRs; can merge in any order, though packaging helps reviewers who build on Mac.