Revert the reload-hold; cut 0.2.0-next.20

[HomemadeToast57]

Backs out the reload-hold shipped in 0.2.0-next.19. Testing showed it reduces the flicker but doesn't fix it, and it isn't worth the complexity it carries.

Why it falls short

Two distinct gaps, both symptoms of one thing:

1. The ceiling. The hold is bounded so continuous editing keeps seeing other people's changes. Past that bound a reload fires mid-flight and the flicker returns — reproduced at 2.6s under sustained writes (40 adds @60ms: row count went 59 → 57, losing two rows).
2. Issue vs apply. It guards when a reload is issued, not when its result is applied. A reload already in flight still lands after the next optimistic row appears and replaces the list without it — which is why the flicker persists at burst boundaries even well inside the ceiling.

Underneath both: any design that replaces the whole list from a server snapshot has a window where that snapshot is stale. Deferring shrinks the window; it can't close it. The fix is to stop replacing the list — merge the changed row by id — not to keep shrinking the window.

Notes

• 0.2.0-next.19 stays on npm. Publishing next.20 moves the next dist-tag off it so fresh installs stop picking it up; npm unpublish is restricted and would break any lockfile already referencing it.
• The reverted work is preserved on preserve/realtime-reload-hold — the measurement harness and the race analysis feed the merge-by-id work.
• 108 tests pass, typecheck and build clean.

🤖 Generated with Claude Code