Review feed-query-performance: remove dead full-scan methods, harden mutation coverage

Remove the full-scan methods the capped-scan optimization replaced
(topLevelPostTxids, countTopLevelPosts, countTopLevelPostsByAddr,
buildReplyCountMap) and their tests, keeping the backwards-compat wrappers.
Add hardening tests to kill 4 mutation survivors (raw scan bound, viewerAddr
fallback). Refresh mutation manifests and Gherkin acceptance-mutation stamps.

By architect.

docs/reviews/feed-query-performance-summary.md

@@ -0,0 +1,100 @@
+# Review summary: feed-query-performance
+
+**Architect review of the refactorer handoff for task `feed-query-performance`.**
+
+## Commits reviewed
+- `df39b47` (specifier): Spec feed query performance — per-page reply counting and
+  capped total scan (`feed-query-performance.feature`), and update
+  `efficient-post-pagination.feature` to the per-page reply-count assertion.
+- `65e85c9` (coder): Implement capped-scan feed query for `/posts/recent` —
+  `PostQuery.scanRecentPostTxidsAndCount` with `TOTAL_SCAN_CAP=10`, per-page
+  reply counting via `countRepliesForTxids`, and acceptance handlers/fixture for
+  the new spec.
+- `2455745` (refactorer): Reduce CRAP in the capped-scan query — extract
+  `PostQuery.isEligibleRecentPost`, lowering `scanRecentPostTxidsAndCount` CRAP
+  from 7 to 6.
+
+Merged onto the architect worktree on `swarmforge-architect`.
+
+## Architectural findings and fixes applied
+The structure is sound and consistent with the codebase's layered layout.
+UI/Core separation and the dependency rule hold: `ListRecentPosts` (use case)
+calls the `PostQuery` adapter (near-IO) through its interface, and the
+optimization correctly replaced the two full-index scans (`countTopLevelPosts`
+over all of `postHeights`, `buildReplyCountMap` over all of `postChildren`) with
+a single capped scan plus per-page reply counting. Information hiding is good:
+`TOTAL_SCAN_CAP` is internal to the adapter, and the use case only sees
+`{ txids, total }`. The refactorer's `isEligibleRecentPost` cleanly isolates the
+reply/mute eligibility check.
+
+**Dead-code removal applied (cohesion / information hiding):** the optimization
+left the old full-scan methods dead in production — `topLevelPostTxids`,
+`countTopLevelPosts`, `countTopLevelPostsByAddr`, and `buildReplyCountMap` were
+referenced only by unit tests. These are the exact slow paths the task
+eliminated, so leaving them in the adapter was a latent hazard (accidental
+reintroduction of the slow path). I removed them and their unit tests.
+`loadReplyTxids` was kept (still used by `scanFollowingFeedTxidsAndCount`), and
+the thin backwards-compat wrappers `scanRecentPostTxids` / `scanPostsByAddrTxids`
+were kept consistent with the existing convention.
+
+**Test hardening applied (kill mutation survivors):**
+- `psf-memo-db/test/unit/adapters/post-query.unit.js`: added a raw-scan-bound
+  test asserting the scan stops at exactly `offset + limit + cap` entries —
+  kills the `rawCount = 0 -> 1` and `rawCount >= maxRaw -> >` survivors.
+- `psf-memo-db/test/unit/use-cases/list-recent-posts.unit.js`: added
+  `viewerAddr` forwarding and `viewer` fallback cases — kills the
+  `viewerAddr || viewer || null -> &&` survivor.
+
+No other production source changes were required; the only non-test source diffs
+are tool-generated mutation manifests.
+
+## Verification results
+
+### Language mutation (`mutate4javascript`, full coverage, `--max-workers 8`)
+- **psf-memo-db**
+  - `post-query.js`: 42 killed, **0 survived**, 0 uncovered.
+  - `list-recent-posts.js`: 2 killed, **0 survived**, 0 uncovered.
+
+### DRY (`dry4javascript`)
+- Changed files (`post-query.js`, `list-recent-posts.js`): **no duplicate
+  candidates**.
+- Full DB `src/`: pre-existing pattern-boilerplate (follow/mute/topic state
+  use-cases, follow/mute controllers and adapters) — unrelated to this batch and
+  left consistent with convention.
+
+### CRAP / cyclomatic complexity (`crap4javascript`)
+All changed functions are well below the 8.0 threshold. Highest:
+`PostQuery.scanRecentPostTxidsAndCount` (CC 6, 100% cov, CRAP 6.0),
+`PostQuery.buildLikeCountMap` / `likeTxidFromPostLike` /
+`scanFollowingFeedTxidsAndCount` / `scanPostsByAddrTxidsAndCount` (CC 5, 100%
+cov, CRAP 5.0), `ListRecentPosts.execute` (CC 4, 100% cov, CRAP 4.0).
+`isEligibleRecentPost` CC 3, 100% cov.
+
+### Soft Gherkin acceptance mutation (`gherkin-mutator --level soft`)
+- **psf-memo-db** `feed-query-performance.feature`: 25 executed, **5 survived**
+  — all `limit` and `max_entries` parameter mutations. The fixture holds more
+  posts than the mutated `limit` (so the returned page is unchanged), and the
+  `max_entries` assertions are upper bounds still satisfied after mutation.
+  Genuine equivalents / weak example-to-assertion connections (specifier-side
+  feature-quality items).
+- **psf-memo-db** `efficient-post-pagination.feature`: 30 executed, **6 survived**
+  — all `limit` and `max_iterations` parameter mutations, same class of genuine
+  equivalents as above.
+
+No implementation changes are warranted for the soft-mutation survivors; they are
+intrinsic equivalents or feature-quality items for the specifier.
+
+## Suite status
+- `psf-memo-db`: unit **345 passing** (was 342; +3 hardening tests, −4 dead-method
+  tests), property **40 passing**, acceptance **pass** (all feature files,
+  including the new `feed-query-performance`), lint **pass**.
+
+## Handoffs sent
+- `git_handoff` to coder and refactorer (`priority: 00`) with the feed-query
+  performance review commit containing the dead-code removal, test hardening,
+  refreshed mutation manifests, and Gherkin acceptance-mutation stamps for the
+  batch features.
+- No specifier handoff: no functional or spec change in this commit (only
+  dead-code removal, test hardening, and tool-generated manifests/stamps).
+
+By architect.