Apply fixes from CodeFactor

[codefactor-io]

This pull request applies fixes from code review by CodeFactor.

---

For more information, click here.

---

Summary by cubic

Use modern Stream.ReadAsync overloads with CancellationToken and Memory across the downloaders, update service, and the PCM16 WAV extractor. This simplifies the code, aligns with CodeFactor recommendations, and keeps behavior the same.

^{Written for commit de68e6d. Summary will update on new commits.}

Confidence Score: 4/5

Safe to merge — the API migration is functionally equivalent in all four files; the only issues are two indentation defects introduced by the bot.

The ReadAsync migration is correct throughout the PR and carries no behavioral risk. The two broken-indentation lines in ModelDownloaderAdapter.cs and UpdateService.cs are a cosmetic artifact of the automated bot and do not affect compilation or runtime behavior, but they leave the codebase with visibly malformed method chains that would confuse future readers.

Files Needing Attention: ModelDownloaderAdapter.cs and UpdateService.cs — both have the column-0 indentation defect on the newly changed ReadAsync call.

Important Files Changed

Filename	Overview
src/Trackdub.Infrastructure/Licensing/HuggingFaceModelDownloader.cs	Upgraded ReadAsync from the old byte[]/offset/count overload to the modern Memory overload; formatting is clean and the WriteAsync still correctly uses bytesRead as the count.
src/Trackdub.Infrastructure/Licensing/ModelDownloaderAdapter.cs	Same ReadAsync overload upgrade as HuggingFaceModelDownloader, but the CodeFactor bot introduced a formatting defect — the method call is flush against column 0 instead of being indented to match the surrounding chain.
src/Trackdub.Infrastructure/Updates/UpdateService.cs	Same ReadAsync upgrade and same column-0 indentation defect introduced by the bot as in ModelDownloaderAdapter.cs.
src/Trackdub.Media/Extraction/Pcm16WaveClipExtractor.cs	Two ReadAsync upgrades: the header read switches to the full-buffer Memory overload correctly, and the clip-copy loop uses buffer.AsMemory(0, bytesToRead) to preserve the original partial-read semantics. Both are functionally equivalent and correctly formatted.

Prompt To Fix All With AI

### Issue 1
src/Trackdub.Infrastructure/Licensing/ModelDownloaderAdapter.cs:198-200
The CodeFactor bot placed `.ReadAsync(buffer, cancellationToken)` at column 0, breaking the indentation of the method chain. The call should be indented to align with the surrounding code.

```suggestion
                    while ((bytesRead = await contentStream
                               .ReadAsync(buffer, cancellationToken)
                               .ConfigureAwait(false)) != 0)
```

### Issue 2
src/Trackdub.Infrastructure/Updates/UpdateService.cs:299-301
Same column-0 indentation defect introduced by the bot — `.ReadAsync(buffer, cancellationToken)` should be indented to align with the method chain.

```suggestion
            while ((bytesRead = await contentStream
                .ReadAsync(buffer, cancellationToken)
                .ConfigureAwait(false)) != 0)
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "[CodeFactor] Apply fixes" | Re-trigger Greptile}

Greptile also left 2 inline comments on this PR.

[greptile-apps]

The CodeFactor bot placed .ReadAsync(buffer, cancellationToken) at column 0, breaking the indentation of the method chain. The call should be indented to align with the surrounding code.

Suggested change

	while ((bytesRead = await contentStream
	.ReadAsync(buffer, 0, buffer.Length, cancellationToken)
	.ReadAsync(buffer, cancellationToken)
	.ConfigureAwait(false)) != 0)
	while ((bytesRead = await contentStream
	.ReadAsync(buffer, cancellationToken)
	.ConfigureAwait(false)) != 0)

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/Trackdub.Infrastructure/Licensing/ModelDownloaderAdapter.cs
Line: 198-200

Comment:
The CodeFactor bot placed `.ReadAsync(buffer, cancellationToken)` at column 0, breaking the indentation of the method chain. The call should be indented to align with the surrounding code.

```suggestion
                    while ((bytesRead = await contentStream
                               .ReadAsync(buffer, cancellationToken)
                               .ConfigureAwait(false)) != 0)
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Same column-0 indentation defect introduced by the bot — .ReadAsync(buffer, cancellationToken) should be indented to align with the method chain.

Suggested change

	while ((bytesRead = await contentStream
	.ReadAsync(buffer, 0, buffer.Length, cancellationToken)
	.ReadAsync(buffer, cancellationToken)
	.ConfigureAwait(false)) != 0)
	while ((bytesRead = await contentStream
	.ReadAsync(buffer, cancellationToken)
	.ConfigureAwait(false)) != 0)

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/Trackdub.Infrastructure/Updates/UpdateService.cs
Line: 299-301

Comment:
Same column-0 indentation defect introduced by the bot — `.ReadAsync(buffer, cancellationToken)` should be indented to align with the method chain.

```suggestion
            while ((bytesRead = await contentStream
                .ReadAsync(buffer, cancellationToken)
                .ConfigureAwait(false)) != 0)
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[tonythethompson]

Closing as superseded.

main already has the same ReadAsync modernization with corrected indentation (57160e7). This PR branch (de68e6d) is a divergent CodeFactor commit that reintroduces the column-0 indentation Greptile flagged.

CI on this PR also failed because ThrowingReadStream only overrode the old ReadAsync(byte[]) overload; the Memory-based call bypassed the simulated failure. That test fix is on main now.