serve: dedup the optimistic-write scaffold in web/src/store.ts

[andreiRS]

Follow-up from the #13–#26 integration review (quality-only, non-blocking; deferred deliberately because the web layer has no test net — UI testing is browser-only/locked — so a blind refactor carries regression risk).

What

The optimistic / pending / reconcile machinery in web/src/store.ts grew across #19/#20/#21/#22/#23 and now has parallel near-copies:

1. Post-dating-by-sha is copy-pasted 3× (move, create, edit reconcile blocks in applySnapshot):

   const postDates = board.head != null && (p.issuedHead == null || board.head.sha !== p.issuedHead.sha);

   → extract postDatesIssued(head, issuedHead): boolean.

2. The three pending-write bodies (move, createTask, editTask) repeat the same scaffold: capture issuedHead, optimistic apply, set the pending entry, clearDelayTimer + an identical 200ms setTimeout that flips showPending.
   → extract a startPendingTimer(key, set, mapName) (or similar) helper for the delay-gate.

The #23 slice already unified the failure path (handleWriteFailure); this is the remaining issue-path + reconcile-loop duplication.

Out of scope

Leave the per-type landed checks as-is — their semantics genuinely differ (lane membership for move, uuid-in-board for create, confirm-and-drop for edit). This is a DRY pass on the shared scaffold only.

Verification

No automated UI tests exist (locked: browser-only). After the refactor, browser-verify move/create/edit happy + failure paths on the single-origin server, and gate on tsc --noEmit (root + web) + web build.

[andreiRS]

Decision: park (not closing)

Measured the actual win before committing to this.

Line savings: ~15 lines out of 871 (~1.7%), best case.

• postDates extraction (3 sites): 6 lines removed - ~3 line helper = ~3 net
• Timer scaffold (3 sites): ~18 lines removed - ~6 line helper = ~12 net, but the real win is smaller: the helper can only extract the plumbing (clearDelayTimer + delayTimers.set/setTimeout/delete). The set((s) => {...}) body stays at each call site because each touches a different typed map (pending / pendingCreates / pendingEdits), and folding those in loses type safety.

Why park: ~15 lines saved against a refactor of the optimistic-write path that has no UI test net (browser-only, locked) is a poor cost/benefit. The regression risk outweighs the DRY win.

Worth doing only opportunistically: if we're already deep in store.ts for another change and can browser-verify move/create/edit (happy + failure) as a side effect. Not worth a dedicated slice.