The cancel path keeps its selection, not a void helper

[3lvis]

Why

cancelRequest was a void helper with one caller, disabled against no_single_use_void_functions. Underneath it was a pure question — which task carries this method and URL — wrapped in an effect that was one line long.

That question is now firstTask(matching:url:among:), which returns the task and touches nothing. cancelImageDownload reads the session's tasks and cancels what comes back, which is the whole of what the helper was doing for it.

Two things fell out. The SessionTaskType switch offered .data, .upload and .download, and the only caller ever passed .data — the enum had no other user in the package, so it goes with the switch. And the disable comment goes, leaving eight in the package rather than nine.

The approach

I tried the same split on logCompletion and reverted it. Its five record calls were what kept record above the rule's single-caller line; extracting the pure line-builder moved the violation onto record instead of removing it, and record is a file-handle writer that has no business being inlined into a loop. One disable traded for another is not worth a diff.

Behaviour is unchanged, and testCancelImageDownload covers this path already, so there is no new test here.

Testing

make test (180 tests, green) plus bin/lint --check clean.

Learnings

A single-use void helper can be the reason a different function clears the same rule. logCompletion called record five times, so record read as multi-use; pulling the pure half out of logCompletion left record with one caller and the rule moved rather than cleared. Worth counting the callers a refactor removes before assuming an extraction pays.