Response cache stats

[acmel]

● Response cache statistics, startup improvements, and bug fixes

This series adds observability into the response cache, fixes several
bugs found during testing, and improves daemon startup behavior.

Response cache statistics (patches 3-6)

Track per-review cache hit/miss/token counts in the database and expose
them through the API, CLI (sashiko show), and web UI. The web UI uses
tap-to-expand panels with hit-rate progress bars — available per-patch
and aggregated at the patchset level. All cache stats display is gated
behind the show_cache_stats setting (default off).

Example sashiko-cli show output with cache stats enabled:

Patchset Details:
ID: 61
Subject: perf session: Add minimum event size and alignment validation
Author: Arnaldo Carvalho de Melo acme@redhat.com
Status: Failed
Date: 2026-05-19 14:48:09

Patches (28):
[1] perf session: Add minimum event size and alignment validation (Failed) [Failed] {cache: 502/543 hits, 23.1M tokens saved}
[2] perf tools: Fix event_contains() macro to verify full field extent (Reviewed) [Issues Found] {cache: 413/807 hits, 15.7M tokens saved}
...
[27] perf kwork: Bounds check work->cpu before indexing cpus_runtime[] (Reviewed) [Reviewed] {cache: 3667/4155 hits, 163.0M tokens saved}
[28] perf test: Add truncated perf.data robustness test (Reviewed) [Issues Found] {cache: 3080/3334 hits, 134.8M tokens saved}

Cache: 64296/78526 hits (81.9%), 2841.6M tokens saved, 647.2M tokens stored
Model: gemini-3.1-pro-preview

In the web interface, these stats are available by tapping the ▶ indicator
next to each patch row for per-patch details, and on the Model: line in
the patchset header for aggregate stats across all patches.

Startup and operational improvements (patches 2, 11, 12)

• Support user-level config in ~/.config/sashiko/Settings.toml so
  personal credentials and overrides don't live in the repo checkout
• Move custom remote fetches to a background task so the reviewer starts
  immediately instead of blocking on slow git.kernel.org IPv6 fetches
• Log response cache open timing, file size, and entry count at startup

Bug fixes (patches 1, 7-10)

• Fix sashiko show picking a stale "Reviewed" result over a newer
  "Failed" retry after patchset resubmission
• Fix cancel endpoint rejecting localhost connections on dual-stack
  servers (missing to_canonical() call)
• Return proper 404 when cancelling a non-existent patchset
• Stop submitting LLM requests for remaining patches after a patchset
  is cancelled

Docs (patch 0)

• Extract LLM provider configurations into examples/ directory

I'll work now on adding limits to the cache and hopefully some sort of LRU to keep LLM requests that have tons of hits while making space for new entries by purging seldom used ones and then make the request cache a default feature with a given reasonable size based on the experience we gather by exposing the stats using this patch series publicly, which is something I encourage the admin for https:://sashiko.dev to do when upgrading to the next release.

Saving "I know that this is not something introduced by your patch, but there is this pre-existing problem that I analysed and found problematic, can you postpone submitting this series and fixing just this one more issue, pretty please?" cases in some sort of database that gets exposed in the https://sashiko.dev site in one special session of "please help picking up from this cache of query/response tokens cache of problems" is another idea I plan to work on Real Soon Now. :-)

 @@@@@Cheers,

Signed-off-by: Arnaldo Carvalho de Melo acme@redhat.com

[derekbarbosa]

Hi @acmel, thank you for the PR.

Here's gemini's output via the /review-pr skill, vetted through a few passes.

  Below are the findings from the review, followed by an adversarial check.

  🔴 Safety / Bugs
   * src/main.rs:L252: 🔴 Safety: The custom_remotes fetch is moved to a background task using tokio::spawn. While this correctly prevents blocking the startup, it uses a shared
     repo_path. Ensure sashiko::git_ops::ensure_remote handles concurrent access or that the reviewer service doesn't try to use these remotes before they are initialized. Since
     ensure_remote is async, it likely involves process-level locking or atomic git operations, but a race condition where a review starts for a remote that isn't fully fetched yet might
     result in a "Remote not found" error instead of waiting.
       * Fix: The code relies on the reviewer calling ensure_remote itself if it misses. This is a safe fallback. No immediate action required, but monitor for "Failed to ensure custom
         remote" logs.

  🟡 Complexity / Logic / SOLID
   * src/reviewer.rs:L568 & L628: 🟡 Logic: Added cancellation checks in the worker loops. Draining the queue (queue.lock().await.clear()) is effective for stopping further processing.
     However, if multiple worker threads detect cancellation simultaneously, they all attempt to clear the same shared queue.
       * Fix: Use an atomic or a more coordinated "kill switch" (like a CancellationToken) if this causes lock contention, though given the context, the current implementation is
         acceptable for stopping the review process.

Other than that, the db changes look safe. @rgushchin I am not sure how you handle the database migrations for adding new columns but if they are allowed to be null, then it should be fine.

[derekbarbosa]

My only qualm is the safety finding in main and potentially the logic bug. Once those get fixed -- LGTM

[acmel]

Thanks for the review, Derek!

On the two Gemini findings:

1. Safety (main.rs background remotes): This is by design — the reviewer calls ensure_remote() itself when it encounters a RemoteTarget baseline, so patchsets targeting a custom remote will wait for the fetch at that point. Other patchsets proceed without delay. The comment in the code documents this.

2. Logic (reviewer.rs queue drain): Multiple workers calling queue.lock().await.clear() on an already-empty Vec is a no-op — there's no contention issue. Each lock acquisition is instant (just clearing or popping a single element).

On the migration question: yes, all four new columns (cache_hits, cache_misses, cache_tokens_saved, cache_tokens_stored) are added via try_add_column("reviews", ..., "INTEGER") with no NOT NULL constraint, so they default to NULL for existing rows. No backfill needed.

[acmel]

I'll force push now with the merge conflicts resolved.