Audit the public interface for usage of the internal runtime

[pkhuong]

In #15, we observed an issue with the public interface's transitive use of Verneuil's internal async runtime. I don't believe there's any left (everything else just pushes work to the internal threads or uses fresh worker threads), but let's make extra sure.

[pkhuong]

Callers of call_with_executor:

• copier::consume_directory
• copier::ensure_bucket_exists
• CopierWorker

Callers of block_on_with_executor:

• copier::ensure_bucket_exists
• copier::touch_blob
• loader::load_from_source

[pkhuong]

Callers of consume_directory (internal to copier.rs):

• force_full_snapshot (called only from CopierWorker)
• CopierWorker

Callers of ensure_bucket_exists (internal to copier.rs):

• create_target (called only from CopierWorker)

Callers of touch_blob (internal to copier.rs):

• CopierWorker.

In copier.rs, we only have to highlight that CopierWorker uses its own internal runtime.

[pkhuong]

loader.rs already has a rayon thread pool for loader operations. We can make sure load_from_source always runs its logic on a worker thread from that pool.

[pkhuong]

copier.rs does not expose CopierWorker. It's passed to the threads created by CopierBackend::new, and called from copy_spool_path. We'll just document the potential trap.