fix(server): handle streamed runner log redirects

What changed

• Avoid installing the streaming :into callback on the initial GitHub Actions logs API request.
• Stream only the redirected signed log archive URL, where the actual log body is returned.
• Normalize Req’s streamed {:ok, {%Req.Request{}, %Req.Response{}}} result shape before status handling.
• Update the worker tests to mimic the real production flow: GitHub API 302 first, signed URL stream second, and tuple-shaped streamed responses.

Why

#11126 correctly stopped Req from automatically following GitHub’s log redirect, which avoided forwarding the GitHub App installation token to the signed archive URL. However, the worker still attached the streaming callback to the initial GitHub API request and still matched only plain %Req.Response{} values.

In production Req returned the 302 as {:ok, {%Req.Request{}, %Req.Response{status: 302}}}. That prevented the manual redirect branch from matching and produced the case_clause Sentry issues. The same tuple shape also tripped Req telemetry, producing the paired badmap alerts.

Impact

Runner job log ingestion should now follow GitHub’s signed archive redirect without leaking the installation token and without generating paired Sentry notifications for every completed job log fetch.

Validation

• mix test test/tuist/runners/workers/fetch_logs_worker_test.exs passed: 10 tests, 0 failures.
• git diff --check passed.