fetch_file_patches discards all errors silently — callers receive empty patch data with no signal

[ooloth]

Current state

PR enrichment data (file diffs and patches) silently disappears when fetch_file_patches fails. The function catches all errors via result.unwrap_or_default() at lines 461–462 of clients/src/github.rs, returning an empty map without logging or propagating the failure. Callers treat the empty result as "no patches" rather than "fetch failed" — a network error, auth failure, or JSON parse error are all indistinguishable from a PR with no changed files.

Ideal state

• fetch_file_patches returns Result<HashMap<…>> so callers can propagate or observe the failure
• enrich_with_file_patches logs the failure at error level when fetch_file_patches returns Err, including the PR number and error cause
• Callers that receive an empty patch set due to a failure can distinguish it from a PR with no changed files

Starting points

• clients/src/github.rs lines 441–462 — fetch_file_patches function and the unwrap_or_default() call
• clients/src/github.rs — enrich_with_file_patches call site

QA plan

1. Introduce a deliberate error path in fetch_file_patches (e.g. return Err(anyhow::anyhow!("injected")) at the top of the function)
2. Open a PR in the TUI that has file diffs — expect the TUI to still display the PR (not crash) and the log to record the fetch failure with the PR number
3. Verify the PR row is still visible with an empty diff section, not missing entirely
4. Restore the real implementation — expect diffs to appear normally for PRs with changed files

Done when

A failure in fetch_file_patches produces a log entry with the error cause and PR context, and never silently returns empty data to a caller that cannot distinguish failure from "no diffs".