fix(synthesis): accepting a proposal no longer jumps the scroll

[bryanmatthewsimonson]

The bug

Clicking Accept on a corpus-synthesis proposal jumped the page to the bottom every time, making it painful to accept a run of proposals.

Root cause

The accept handler fired onChanged → onReloadCase → render() — a full portal re-render. render() rebuilds #xr-view, and the synthesis block repopulates asynchronously, so the scroll position reset (landing at the bottom) on every single accept. The re-render was also redundant: the handler already marks the row ✓ in place and persists through the model firewalls (EvidenceLinker / ClaimModel) independently of any render.

Fix

Drop the per-accept re-render. renderProposals now gives in-place feedback only:

• the accepted row marks ✓ (as before),
• the "Proposals — review and accept (N)" count ticks down live,
• a hint appears: "N accepted — Refresh to fold them into the case view."

The graph/dossier reflect accepted claims/links on the next Refresh (the natural batch workflow), never mid-triage. Dismiss already used row.remove() (no re-render) and was unaffected — it now also decrements the count. onChanged is removed from the renderProposals contract and its wiring in synthesis-block.

Membership add/remove keeps its own onReloadCase (a different path) — unchanged.

Verification

• npm test → 1976 pass · npm run build clean · npm run lint 0 errors.
• Behavior is DOM-only (no re-render call, in-place count); the pure partitionProposals tests still cover the triage partition.

Manual check after merge: open a case with proposals, scroll to one mid-list, Accept several in a row — the view should stay put, each row flips to ✓, and the count decrements.

🤖 Generated with Claude Code