Deck list: expose per-deck fields needed for search/filtering (anki desktop / core)

**Context:** AnkiMobile is considering building / redesigning deck-list search/filtering. Some needed facets require new fields; this ticket covers only those. (Facets already free from the existing `DeckTreeNode` response are out of scope here.)

### 1. Last-studied timestamp per deck
`DeckCommon.last_day_studied` already exists but isn't surfaced on `DeckTreeNode`. Add it (or a lightweight batched lookup) so clients can show/filter on recency without a per-deck round trip.

### 2. Note count per deck
`DeckTreeNode` only carries card counts (`total_in_deck`, etc.). Needs a note-count equivalent, batched across the tree in one call rather than per-deck.

### 3. Scheduling preset (`config_id`) per deck
Lives on `Deck.Normal` today, not on `DeckTreeNode`. Exposing it on the tree (or a batched lookup) enables a "filter by preset" facet — also useful independently for surfacing "this preset affects N other decks" wherever a preset gets edited.

### 4. Retention % per deck — proposed, likely its own ticket
No caching/batch mechanism exists for retention anywhere in the codebase today — every computation (including the existing single-deck Stats screen) does a full revlog scan per request ([[stats/graphs/mod.rs:36-56](https://claude.ai/epitaxy/rslib/src/stats/graphs/mod.rs:36)](rslib/src/stats/graphs/mod.rs:36)). That's fine for one deliberately-opened deck; not fine for N decks rendered in a scrolling list simultaneously.

Three possible paths, increasing in backend investment:
- **Lazy, visible-rows-only fetch** — no schema change, client requests retention only for on-screen decks via the existing scoped graphs call. Bounds concurrency but doesn't fix underlying cost.
- **Cached snapshot, refreshed periodically** (e.g. per sync or daily) — reuses existing scan logic, just runs less often and stores the result. Needs a "stale as of" concept in UI.
- **Incremental counters**, same pattern as `new_studied`/`review_studied` — cheapest read, but all-time-only unless windowed (real new state), and needs a one-time backfill migration for existing collections.

Flagging now: if retention % is judged too large a unit of work to bundle with items 1–3, it should split into its own ticket rather than block them.

### Out of Scope

- Integration into Anki Desktop, Mobile, Web, or any Ankiclient; this ticket merely makes these stats / facets available for client consumption.

### Non-goals
- No changes to search/query syntax.
- No changes to how retention is computed for the existing single-deck Stats view — this is about making a *list-safe* version available, not replacing that.

Start by tracing DeckTreeNode and the existing DeckCommon.last_day_studied, Deck.Normal.config_id, and note/card count paths. Use rslib/src/stats/graphs/mod.rs:36-56 to understand the current per-deck retention scan. Done means items 1–3 are exposed through one batched tree-safe path; decide whether retention is split into a separate ticket before implementing it.

Written by the indexing model from the issue text.