The feed stays light at thousands of posts

A Perf test (tests/e2e/Perf/FeedPerfTests, Category=Perf) scrolls load0's
home, thousands of posts from SocialPub's load runs, to 2000 posts. Before:
100 cards took 12 s to reach, 1000 took 437 s, 2000 took 29 minutes; the
main thread was busy almost all of that time, and the page held 224 000 DOM
nodes and 920 MB of .NET heap. Every card re-rendered whenever the list did.

- A card re-renders only when its own events run or its render key changes
  (Content.RenderKey: the post, its status, notification, conversation,
  place and grouping, where it is shown, the persona and the connection).
  2000 cards then took 122 s.
- The list is a <Virtualize>: only the cards near the view are rendered.
  The page now holds about 3 000 DOM nodes and 145 MB however long the feed
  is, and each page of older posts costs the same (about 1.9 s in the test's
  scroll loop) at the 100th post as at the 1700th. The feed tells how many
  posts it holds in data-feed-count.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LsXgEaXee4GCU1hwYgPJXw

CLAUDE.md

@@ -67,7 +67,11 @@ tests/e2e/run.sh [--filter ...]   # publishes with WasmApplicationEnvironmentNam
 - **The tests ask the town** (`Support/Pasture.cs`) which accounts exist and what each object holds (`town.sh expect`),
   and check the other side of the wire through `town.sh stored`. Each render and action test is also a cell of the
   town's report (`out/client.jsonl`).
-- Cards carry `data-uri` (their ActivityPub id) and the empty feed `data-feed-empty`, for the tests.
+- Cards carry `data-uri` (their ActivityPub id) and the empty feed `data-feed-empty`, for the tests. The feed renders
+  only the cards near the view, so a test looks for recent cards, and counts what is loaded by `data-feed-count`.
+- **Perf** (`Perf/`, `Category=Perf`, left out of the normal runs with `--filter "Category!=Perf"`): `FeedPerfTests`
+  scrolls load0's home (thousands of posts from SocialPub's `load.sh`) to 2000 posts and writes, per step, the time,
+  DOM nodes, JS and .NET heaps and long tasks to `perf.json`.
 - The root project globs `**/*.cs`, so it excludes `tests/**` (`DefaultItemExcludes`), and Tailwind does not scan it.
 
 ## CSS: Tailwind 4 + daisyUI 5, vendored, offline
@@ -284,6 +288,11 @@ supplies:
   streaming API (`Services/StreamingService.cs`: one WebSocket, the persona's token as its protocol, never in a URL)
   for home, lists, local, federated, hashtags and notifications, and wait behind a "new" button; a deletion or an edit
   it tells applies at once. Other feeds, and any feed while the stream is down, are polled every 45 s while visible.
+  - **At volume:** the list is a `<Virtualize>` (only the cards near the view are rendered), and a card re-renders only
+    when its own events run or its render key changes (`Content.RenderKey`: the post, its status, notification,
+    conversation, place, grouping, where it is shown, the persona and the connection). Anything that changes what a
+    card shows from outside it must replace one of those objects or be added to the key; mutating one in place leaves the
+    card as it was. Without these a feed took seven minutes to reach a thousand cards and held 900 MB at two thousand.
 - **The globe** (`wwwroot/js/globe.js`, an ES module imported by `GlobePanel`) runs on globe.gl, vendored in
   `wwwroot/vendor/globe/` with its textures and `countries.json` (`SOURCES.md` has versions, licences and hashes; the
   service worker never precaches it). It looks at the spherical mean of the located posts in view, pulses and draws an