fix(http): avoid nested tokio runtime panic in download path

The CurlDownloader owned a tokio runtime and block_on'd reqwest from its
sync tick(), while the repository/installer/downloader sync bridges each
created another Runtime and block_on'd async fns that reach that leaf.
Driving one Runtime::block_on from within another panics with "Cannot
start a runtime from within a runtime", hit by `require` when fetching
p2 metadata.

Switch CurlDownloader to a blocking reqwest client (its own internal
thread, never nested) and replace the per-call Runtime::new().block_on
bridges with a no-reactor sync_executor::block_on helper. No awaited
future parks on a reactor once the only async I/O is blocking, so the
helper can be nested freely.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

1 files changed, 1 insertions, 3 deletions

diff --git a/crates/shirabe/src/util/sync_helper.rs b/crates/shirabe/src/util/sync_helper.rs
index 8988795..1014b86 100644
--- a/crates/shirabe/src/util/sync_helper.rs
+++ b/crates/shirabe/src/util/sync_helper.rs
@@ -179,9 +179,7 @@ impl SyncHelper {
         promise: Option<std::pin::Pin<Box<dyn std::future::Future<Output = Result<()>> + '_>>>,
     ) -> Result<()> {
         if let Some(promise) = promise {
-            tokio::runtime::Runtime::new()
-                .unwrap()
-                .block_on(r#loop.borrow_mut().wait(vec![promise], None))?;
+            crate::util::sync_executor::block_on(r#loop.borrow_mut().wait(vec![promise], None))?;
         }
         Ok(())
     }