app: timeline row reconciliation uses Effect deep equality on every stream delta

Description

Every time the session timeline updates, reuseTimelineRows compares each new row against the previous one with Effect's Equal.equals. For a 320 turn session that is 1,288 rows per streamed delta, and each comparison walks the whole row structure, including every message and part ref inside PartGroup. While a reply streams, about a third of JS samples in a profile land in Effect's equal/hash code.

A comparator that switches on the row's _tag and compares only that variant's fields does the same job much faster. Isolated benchmark over a 1,288 row timeline, 1,000 updates per run, one process per build: 11.5 ms per update before, 0.64 ms after. The browser profile shows no samples in Effect equal/hash after the change.

Steps to reproduce

1. Open a session with 300 or more turns in the web app.
2. Send a message and let the reply stream.
3. Record a performance profile while it streams.
4. The timeline rebuilds and compares all rows on each streamed part delta, so equal/hash samples grow with the stream.

OpenCode version

dev, commit 193de13.

Operating System

Linux x86_64.

Terminal

Not applicable, this is the web app.

A draft PR with the fix and measurements: #48435