Audit and fix silent error suppression (`let _ =`) in Rust backend

[ryuhmanov-m]

Parent issue: #20

Context

The Rust backend has multiple let _ = ... patterns on I/O operations (file writes, database calls, IPC). These silently swallow errors, making debugging difficult.

Scope

1. Grep for let _ = across src-tauri/src/
2. For each occurrence, determine if the error should be:
   • Propagated (? operator) — for operations where failure means the parent should fail
   • Logged (if let Err(e) = ... { tracing::warn!(...) }) — for best-effort operations
   • Kept as let _ = — only for truly fire-and-forget cases (e.g., channel send where receiver may have dropped)
3. Replace let _ = with the appropriate pattern

Guidelines

• Use tracing::warn! or tracing::error! for logged errors
• Include context in log messages: what operation failed and why it matters
• Don't change function signatures unless necessary

This is a great issue for learning the Meld codebase and Rust error handling patterns.

[code4th]

I did a quick static pass over this issue and found 87 let _ = matches under src-tauri/src.

The count is high, but it looks like it can be split into a few different buckets instead of handled as one giant cleanup:

• likely keep/document: test cleanup and tx.send(...) stream notifications where a dropped receiver can be expected
• log with context: UI emit failures, best-effort auto-commit failures, OAuth callback socket write/flush failures
• propagate or make explicit: database/run-store writes and non-optional persistence paths

The highest-signal first PR slice seems to be:

1. src-tauri/src/adapters/emitter.rs:18 - log failed app.emit(...) with channel context, since this directly explains "backend kept going, UI looked frozen".
2. src-tauri/src/adapters/vectordb/mod.rs:136/159/169 - log run-store write failures (create_run, append_run_event, finish_run) because losing these makes later debugging much harder.
3. src-tauri/src/adapters/mcp/mod.rs:874/1045/1072 - log failed best-effort auto_commit_files(...) calls so knowledge-base writes do not silently lose their follow-up commit.

I would avoid changing the many provider tx.send(...) cases in the same PR unless the project wants a separate policy for dropped stream receivers. They are probably a different class from ignored filesystem/database/UI errors.

I have not run the project test suite in this pass; this is just a triage slice to make the first contribution smaller and easier to review.