[wefio]

What this fixes

The search window read the oldest pending entries. Measured on the deployed service with
twenty sequential Adds to one user (below the fold trigger, so nothing folded):

pending_entries = 20
marker  0 -> FOUND      marker  8 -> MISSING
marker  3 -> FOUND      marker 12 -> MISSING
marker  7 -> FOUND      marker 19 -> MISSING

The window held the first eight entries and hid the rest, and nothing recovers them: a search
never folds (by design), and the fold is triggered by the pending counter, which only moves on
Add. In steady state pending sits between 16 and 23, so the affected entries are the newest
8–15 - exactly the ones a streaming update just added.

The change

• listPending takes an optional newest: it slices the tail of the key list before reading
  any body (names sort in arrival order, so skipped entries cost no GET) and returns the tail
  of the matches.
• pendingForSearch passes it. The fold does not, so entries are still applied in arrival
  order.
• One test pins both directions, because pinning only one would look correct.

Cost: the newest branch reads every body in its tail window before slicing, since the
generation filter must see them - up to about fifteen small objects per search at the observed
pending ceiling. That is latency traded for correctness, and it is the only thing to watch.

Verification

• npm run verify in onlion: 34 PASS (the new assertion included), eslint clean.
• docs:check passes; the decision record gained a section with the measurement above.
• After deployment: the same marker experiment, expecting marker 19 to be FOUND.