refactor(server): give the four LRU eviction min_by_key calls a total order

[inureyes]

Summary

Four LRU eviction sites picked their victim with min_by_key applied directly to a HashMap iterator: Inner::evict_oldest and Inner::evict_oldest_snapshot in src/server/prompt_cache/store.rs:315 and :336, and evict_to_capacity in both src/server/responses_store.rs:243 and src/server/conversation_store.rs:151. Iterator::min_by_key returns the FIRST minimum, so two entries tied on the timestamp key would be separated only by HashMap iteration order, which RandomState randomizes per map instance.

This is not a live bug, and it is not described as four bugs here. All four keys are std::time::Instant, and every writer (touch(), insert(), get(), append()) stamps a single entry with one Instant::now() call. At nanosecond resolution the tie is not reachable through the public API today. What this PR removes is a latent fragility: the pattern would become a real defect the moment one of these keys becomes coarser than a per-call Instant (a seconds-granularity timestamp, a logical clock, a value hoisted out of a loop), and nothing in the current code flags that risk.

What changed

• src/server/prompt_cache/store.rs, evict_oldest (line ~315) and evict_oldest_snapshot (line ~336): both now key on (slot.entry.last_used(), *digest.as_bytes()). PromptCacheKeyDigest derives only Clone, Copy, PartialEq, Eq, Hash and is not Ord, so a bare tuple key would not compile. Per the issue's recommendation, I keyed on *digest.as_bytes() (&[u8; 32], which is Ord) rather than adding PartialOrd, Ord to the digest's derive, to avoid widening that type's public trait surface for one call site. last_used() is still called exactly once per element (the key-function closure runs once per item), so this does not turn the per-entry mutex lock into a double lock.
• src/server/responses_store.rs, evict_to_capacity (line ~243): switched to min_by with a.last_accessed.cmp(&b.last_accessed).then_with(|| key_a.cmp(key_b)). The key is a String, so the comparator form avoids the clone a tuple key would force.
• src/server/conversation_store.rs, evict_to_capacity (line ~151): same comparator form.
• Each site carries a comment naming the tie-break component (digest bytes or map key) as what makes the order total, per docs/code-guidelines.md's "HashMap Iteration Order" section, so a later simplification pass does not read the component as redundant and strip it.

Scope matches the issue exactly: the four call sites plus a comment at each. No change to eviction policy, cap-enforcement loops, or what the stores are bounded by. #1248 (byte-bounding of the two stores) is open but still status:ready with no PR, i.e. not in flight, so this PR keeps all four sites rather than folding two into that work.

Regression test: decision and reasoning

No regression test was added. Reasoning:

• The tie is not reachable through any production write path on any of the four sites (confirmed per site above), so a test would have to write an identical Instant directly into private state, bypassing touch()/insert()/get()/append() entirely.
• Such a test would pin the comparator/tuple-key's generic sort behavior, not any reachable production state. It would not catch a real regression that a code reviewer plus the comment at each site wouldn't also catch.
• The general defect class, its testing methodology (fresh map per iteration, 32+ iterations, an actual constructed tie), and precedent test suites are already recorded in docs/code-guidelines.md's "HashMap Iteration Order" section, including its explicit accounting that these exact four sites are "true positives for the lint and zero live bugs."
• A test becomes worth adding the moment a future change makes one of these keys coarser than a per-call Instant (the actual risk this PR is guarding against) — and that change would introduce its own new code path, which is the natural place for its own review and its own test, not a synthetic test bolted onto code that cannot exercise the coarser key today.

This is a judgment call per the issue's acceptance criteria, which explicitly allow either outcome with reasoning stated. No existing test's expected outcome changed.

Test plan

• cargo fmt --all -- --check — exit 0
• cargo check --lib --tests --features cuda — exit 0
• cargo clippy --lib --tests --features cuda -- -D warnings — exit 0
• cargo test --profile test-fast --features cuda --lib server::prompt_cache — exit 0, 168 passed, 0 failed
• cargo test --profile test-fast --features cuda --lib server::responses_store --no-run then run the built binary filtered to server::responses_store — exit 0, 8 passed, 0 failed
• Same binary filtered to server::conversation_store — exit 0, 5 passed, 0 failed

make verify-test-cuda will be run separately against this branch.

Closes #1291

[inureyes]

make verify-test-cuda on GB10 (CUDA sm_121, Linux aarch64) at bd4bbadf, run with no other cargo process on the box: 8251 passed, 0 failed, 311 ignored, 101 suites, exit 0. The log was scanned for process-level aborts as well as failing tests, since a per-suite tally cannot see a teardown crash: no SIGABRT, no terminate called, no error: test failed.

No delta against an earlier baseline is quoted, because main moved during this work: #1292, #1295 and #1296 landed after the last full gate run here, and the latter two add tests. What is checkable is this branch's own contribution, which is zero: the diff adds no #[test] functions and removes none, so the total matching main's current count is the expected result rather than a coincidence.

cargo fmt --all -- --check, cargo check --lib --tests --features cuda and cargo clippy --lib --tests --features cuda -- -D warnings are all clean on the same tree.