herdr-core: a return during an in-flight seen share, or after an answer upgrade, is told wrong #2781

Follow-up to #2779 (#2690). Two edge cases in how the browser tells POST /api/seen whether a finish's pane was just brought into view (presented: "new" | "held", src/lib/sidebarActivity.tsx). Both were reproduced in Codex's second review round with the sidebar hook test harness.

1. A return while a held share is in flight (or waiting to retry) is lost.
shownAgain requires previous.told === "held", and told is set only once the request answers.

• Repro (hook test): finish 2 of pane A arrives while A is in front, so it is shared as held; keep that request pending; select pane B, then A again; then resolve the request. Shares: [1, "new"], [2, "held"], and no [2, "new"] for the return.
• Effect on herdr-core: if another Herdr client marked the turn unread, coming back to the pane in that window does not raise herdr.seen again; the next finish or the next return does.
• Fix idea: keep a pending presentation per pane. When the person returns while a share is in flight, remember new and send it once that request settles (as new only if no newer finish replaced it), without replaying a look older than an unread told since.

2. An answer upgrade forgets that a finish was already told as new.
An answer upgrade (same finish id, answer fingerprint now known) replaces the SharedFinish, and its told history goes with it.

• Repro (hook test): share finish 1 of A as new without an answer; the answer arrives while A stays in front, so it is shared again as held; select B, then A. Shares: new, held (with answer), new again.
• Effect: one extra herdr.seen write on that return, which can clear an unread another client set after the first look.
• Fix idea: carry told (and any pending presentation) over when an answer upgrade replaces the share of the same finish.

Neither is a regression from before #2779: base never re-marked a turn at all.