Make npackd handle connections concurrently

[imattau]

Summary

• Makes the recursive dependency-install future Send (Pin<Box<dyn Future<Output = Result<()>> + Send + 'a>>) so npackd can tokio::spawn a task per accepted connection instead of handling them serially.
• No behavior change to the install logic itself — this only relaxes the future's bound so it can cross the tokio::spawn boundary.

Test plan

• cargo fmt --all -- --check
• cargo clippy --all-targets --all-features (no warnings)
• cargo test (47 passing, including a new daemon_serves_concurrent_connections test that runs the real run_daemon loop and issues two simultaneous ListInstalled calls over a real socket)
• Manual smoke test: two simultaneous real GetPackage calls against npack's own live Nostr/Blossom release completed in ~11s total instead of ~20s sequential, with responses arriving out of order — confirming genuine concurrent handling, not just non-blocking accept

Not in this PR

GetTransaction/CancelTransaction and progress-event streaming remain future work (tracked in the roadmap). A safe CancelTransaction needs a real cooperative checkpoint in the install path (e.g. between packages in a dependency closure) rather than raw task abortion, which risks leaving the store half-installed — that's a larger, separate change.

🤖 Generated with Claude Code