[Bug]: Silent failures in git explorer error handling

[matiaspalmac]

Describe the bug

Two small spots in the git explorer handle command errors sub-optimally, making it hard to diagnose real failures:

1. get_git_diff returns stdout even when git diff fails

apps/desktop/src-tauri/src/lib.rs — the staged-diff command always returns stdout without checking output.status.success(). If git diff --staged fails (e.g. not a repo, permission issue, corrupt index), the UI gets an empty string and shows "no differences" instead of the real error.

Every other git_* command in the same file already follows the status.success() + return stderr on failure pattern.

2. handleSearchClick has an empty catch that hides handler context

apps/desktop/src/addons/builtin.git-explorer/GitExplorerComponent.tsx:

const handleSearchClick = async (r: SearchResult) => {
  try { ... openFile(...); } catch {}
};

safeInvoke does already log a generic [Tauri Invoke Error] read_file: ... line when the invoke fails, so the failure isn't fully silent. But the empty catch means the handler never contributes any context — you can't tell from the log that the click was a stale search result, nor which r.file_path was being opened.

Cleaner fix: pass { silent: true } to let the handler own the log, and emit a single contextual line (e.g. [GitExplorer] Failed to read file <path>). The sibling handleSearch already logs from the handler, so this keeps the file consistent.

Steps to Reproduce

For (1):

1. Open a non-git folder or a repo in a broken state.
2. Trigger the staged diff view.
3. UI shows empty diff instead of the git error message.

For (2):

1. Run a project search that returns results.
2. Delete / rename one of the matched files from outside the IDE.
3. Click the stale result — nothing happens in the UI, and the only console line is the generic safeInvoke one with no handler context.

Trixty Version

main (post v1.0.8)

OS

Windows

Would you like to fix this bug yourself by sending a PR?

Yes