Unified multi-transfer manager dashboard (webview)

[goanpeca]

Summary

A unified multi-transfer manager — a single panel showing all in-flight and queued B2 transfers (uploads, downloads, sync, batch) with per-item progress, throughput, and pause/resume/cancel/retry.

Why

Today every transfer feature (#56 upload, #57 download, #72 sync, #73 batch) is bound to VS Code's withProgress, which is hard-limited to one task per call (a message + % + optional cancel). It genuinely cannot present many concurrent transfers as a live dashboard with per-item controls and throughput. As soon as a user kicks off a folder upload + a batch download + a sync, the native progress surface falls apart. This is the one place in the whole sdk-parity backlog where native hits a real dead-end.

Why a webview here (and only here)

Per the interaction conventions in #87, native is the default and webviews must clear a high bar. This feature clears it: arbitrary layout with many live rows, per-row controls (pause/resume/cancel/retry), and throughput sparklines are not expressible with withProgress, a TreeView (no live per-row controls/visualization), or a virtual document (static). A WebviewView docked in the B2 view container is the right tool.

Proposed UX

• A WebviewView ("B2: Transfers") in the existing b2Explorer container, listing active + queued + recently-completed transfers.
• Per row: name, direction, % + throughput, and pause/resume/cancel/retry actions wired to the SDK's AbortSignal / transfer controls.
• Transfers from Upload files and folders from the UI (command + drag-and-drop) #56/Download files to a chosen location (Save As / download to folder) #57/Local to B2 sync (mirror a workspace folder to or from a bucket) #72/Multi-select batch operations (delete, download, move multiple files) #73 register with a shared TransferQueue service that this view renders. withProgress remains for single quick transfers; long/multiple ones surface here.

Acceptance criteria

• Concurrent transfers from upload/download/sync/batch appear together with live progress + throughput.
• Each transfer can be cancelled; pause/resume/retry where the SDK supports it.
• The view degrades gracefully (or is hidden with a native fallback) on web/remote/virtual hosts where webviews are constrained — see Declare workspace/host capabilities and handle web/remote/virtual hosts #5.
• No secret/credential is rendered in the webview.

Out of scope (keep focused)

• The individual transfer commands themselves (Upload files and folders from the UI (command + drag-and-drop) #56/Download files to a chosen location (Save As / download to folder) #57/Local to B2 sync (mirror a workspace folder to or from a bucket) #72/Multi-select batch operations (delete, download, move multiple files) #73) — this issue is the shared queue + dashboard they feed.
• A general activity/notification center beyond transfers.

Filed from the fitness-neutral UI re-audit (see #87): the single in-scope capability where a webview genuinely beats every native primitive. All other 22 features stay native.