ref(snapshots): Use async I/O for snapshot image processing

[lcian]

Enters the tokio runtime early with a single block_on call wrapping all
async work, instead of calling block_on multiple times in the upload loop.

• compute_sha256_hash is now async, using tokio::fs::File and AsyncReadExt
  for chunked reading instead of sync std::fs::File / std::io::Read
• File opens for uploads also use tokio::fs::File::open inside the async block
• manifest_entries wrapped in Arc<tokio::sync::Mutex> for mutation inside
  the async block, extracted via Arc::try_unwrap after the runtime completes
• Added fs and io-util tokio features in Cargo.toml

Stacked on #3186.

We're still computing the hash and enqueuing the files sequentially. Eventually we can make this concurrent or even parallel in case we want to use a multi-threaded runtime.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Unnecessary Arc/Mutex when HashMap could be returned directly

Medium Severity

manifest_entries is wrapped in Arc<Mutex<>> and later extracted via Arc::try_unwrap(...).expect(...), but there's no concurrent access — everything runs sequentially in a single async block on a single-threaded runtime. The HashMap could simply be created as a local mut variable inside the async block, mutated directly (no .lock().await needed), and returned as part of the Ok(manifest_entries) result. This would eliminate the Arc, Mutex, try_unwrap, into_inner, and the .expect() panic site entirely.

 

[szokeasaurusrex]

@lcian Can you please check whether this comment is valid before I do a full review 🙏