perf(drafts): rescan saved drafts only when a write can change them - #2906

Follows #2906, now merged.

## Problem

With saved drafts, each keystroke in a draft still re-reads every saved
draft. #2906 stops `draft-places` from rescanning. The Drafts & sent
list (`useDrafts`, mounted for the sidebar badge) still calls
`readDrafts` on every draft write, and `readDrafts`:
- walks every localStorage key;
- `JSON.parse`s each draft and projects it to text;
- re-checks each draft's activity record.

The keystroke changes only one draft.

## Change

- `rereadDraft(session, previous, key)` in `drafts.ts` updates the one
changed entry of the last snapshot, writes its activity record if it
changed, and re-sorts. It reuses the same per-entry code as `readDrafts`
(`draftEntry`, `newestFirst`).
- `useDrafts` keeps the snapshot it last showed. On a write to one draft
key it calls `rereadDraft`. Otherwise it falls back to `readDrafts`.
- `parseDraftView` in `view-state.ts` is the one parse-with-size-limit
step. `listDraftViews` and `draft-places`' membership check now share
it, and `MAX_DRAFT_VIEW_LENGTH` is private again.

## No behavior change

`rereadDraft` returns a snapshot only when it can prove that the
snapshot equals a full read. In every other case it returns undefined,
and the caller does the full read. It falls back when:
- the previous snapshot is limited or unavailable;
- the key is not listed (a new draft);
- the value is not a readable, in-limit object;
- the draft no longer counts (blank);
- the activity records don't match the listed entries one for one (for
example, another window changed a record).

New tests in `drafts.test.ts`:
- One edited draft is re-read exactly as a full read would see it,
across every fallback (blank, new key, limited, malformed, lost record,
a stale `draft:` key).
- A keystroke re-reads only the edited draft, with no localStorage key
walk. This test fails without the change.

## Evidence

Since #2940, Drafts & sent is an opt-in plugin, and the list (and this
change) runs only for users who enable it. Measured on main `a0635285a`
with the plugin turned on, without and with this PR. 2 Linux and 2 macOS
boxes each ran 6 interleaved rounds. The table shows the mean of per-box
medians, with the per-box Δ range in parentheses.

| metric | Linux: plugin on | Linux: + this PR | macOS: plugin on |
macOS: + this PR |
|---|---|---|---|---|
| typing, 100 saved drafts: script | 348.0 ms | −17.1% (−17.9..−16.2) |
264.1 ms | −12.5% (−14.1..−10.9) |
| typing, 100 saved drafts: busy | 722.0 ms | −8.0% (−10.2..−5.8) |
507.1 ms | −6.8% (−7.3..−6.4) |
| typing, 100 saved drafts: key-to-paint | 35.8 ms | −1.4% | 20.9 ms |
−3.6% (−4.8..−2.4) |
| mention typing, 100 saved drafts: script | 1383.9 ms | −2.9%
(−3.6..−2.2) | 895.5 ms | −5.3% |
| palette typing, 100 saved drafts: script | 1620.7 ms | −0.9% (noise) |
1086.9 ms | −0.6% (noise) |
| channel switch: script | 488.1 ms | +0.2% (noise) | 276.7 ms | +0.0%
(noise) |

With the plugin off (the default), the list is not mounted and this PR
changes nothing measurable: on `fa5bf08f7`, typing with 100 saved drafts
was −10.4% (#2906 alone) vs −11.7% (with this PR) on Linux and −13.6% vs
−13.4% on macOS.

Lower is better. The typing benchmark (an Event Timing harness on the
browser fixture) runs a production build in Chromium at 4× CPU
throttling and types 12 keys per phase. Before typing, 100 copies of the
composer's own saved draft are seeded into other channels. Key-to-paint
is the Event Timing keydown duration averaged over every key; keys under
16 ms count as 0.

Checks:
- vitest for `drafts-sent`, `view-state` and `draft-places` passes (91
tests).
- `tsc` and `biome` pass.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Signed-off-by: Kalvin Chau <[email protected]>
Co-authored-by: Claude Opus 5.5 <[email protected]>