v1.0.1 — pv.youtube service preflight + sidecar runtime revert

Two fixes after a 2026-05-23 regression where a Kodi restart left
plugin.video.youtube's service.py un-started, breaking every delegated
play with a silent "Service IPC - Monitor has not started" error.

- Addon: probe pv.youtube's localhost httpd (50152/50153) before
  delegating. If nothing is listening, show a "YouTube service down —
  restart Kodi" notification and fall back to our DASH / progressive
  paths instead of letting setResolvedUrl fail silently.

- Sidecar: revert tokio runtime from current_thread back to
  multi_thread with 2 worker threads so subscriptions_feed's per-channel
  tokio::spawn fan-out runs in parallel. The current_thread RSS savings
  weren't worth the behavioral change.

sidecar/Cargo.toml

@@ -3,7 +3,7 @@ resolver = "2"
 members = ["crates/torttube-sidecar"]
 
 [workspace.package]
-version = "1.0.0"
+version = "1.0.1"
 edition = "2021"
 license = "GPL-3.0-or-later"
 authors = ["Cobb <cobb@sulkta.com>"]

sidecar/crates/torttube-sidecar/src/main.rs

@@ -146,12 +146,10 @@ impl Response {
 }
 
 // One-shot sidecar — each invocation handles a single JSON request and exits.
-// current_thread runtime keeps RSS smaller per spawn (~100KB savings vs the
-// multi-thread runtime), which matters when the addon does many calls per
-// Kodi session. Concurrent fan-out in subscriptions_feed uses tokio::spawn
-// onto this same runtime — current_thread is single-threaded but cooperatively
-// multi-tasks via futures, fine for I/O-bound rustypipe + reqwest calls.
-#[tokio::main(flavor = "current_thread")]
+// Two worker threads so subscriptions_feed's tokio::spawn fan-out across many
+// channels actually runs in parallel; the per-spawn RSS cost is negligible at
+// addon-call cadence.
+#[tokio::main(flavor = "multi_thread", worker_threads = 2)]
 async fn main() -> anyhow::Result<()> {
     tracing_subscriber::fmt()
         .with_env_filter(