fix(csharp): key CloudFetchDownloader.downloadTasks by ChunkIndex

[msrathore-db]

Summary

Re-keys the active-downloads bookkeeping dictionary in CloudFetchDownloader.DownloadFilesAsync from <Task, IDownloadResult> to <long, Task> so the continuation's TryRemove actually removes its own entry.

Background

The dict was declared as:

var downloadTasks = new ConcurrentDictionary<Task, IDownloadResult>();

…and populated with downloadTasks[downloadTask] = downloadResult, where downloadTask is the continuation returned by DownloadFileAsync(...).ContinueWith(t => { ... }).

Inside the continuation lambda, however, t is the antecedent task (the DownloadFileAsync task itself), not the continuation. So:

.ContinueWith(t =>
{
    ...
    downloadTasks.TryRemove(t, out _);  // never matches; entries accumulate
});

Entries are never removed. The dict grows entry-by-entry for every chunk in a query and is only freed when DownloadFilesAsync returns (the variable goes out of scope). Task.WhenAll(downloadTasks.Keys) at the end-of-results guard ends up awaiting every download started in the query, including the ones that finished hours earlier — harmless because awaiting completed tasks is essentially free, but wasteful and the code's claim that the dict tracks active downloads is wrong.

Fix

• Key the dict by downloadResult.ChunkIndex (a long, already unique per chunk in a query).
• Capture chunkIndex before the lambda so the closure can use it for TryRemove.
• Update Task.WhenAll to use .Values (the tasks now live as values, not keys).
• Drop the IDownloadResult value type — verified by reading every reference that the value was never read out of the dict (only assigned, removed without being read, or ignored via out _); the IDownloadResult referenced inside the continuation comes from the foreach loop variable via closure capture, not from a dict lookup.

Why a separate PR

This came up during review of #183 (straggler download mitigation). It's not straggler-related — the bug pre-existed in the generic CloudFetch download loop. Splitting it out so it can be reviewed on its own merits.

Test plan

• dotnet build succeeds with 0 warnings, 0 errors
• All 693 unit tests pass (dotnet test --filter "FullyQualifiedName~Unit")
• CloudFetch E2E tests against a live workspace (requires endpoint config — local run failed all 21 in 1ms each on connection setup; not caused by this change)

This pull request and its description were written by Isaac.