Incremental counterpart to .../conversations/sync (phase 3).

The full-sync endpoint re-uploads the WHOLE history every sweep — during a long turn the owning core re-sends a growing 1-2 MB body every 10s, and the server re-parses it. This endpoint takes only the messages appended since the core's last successful push:

{ "base_seq": N, "messages": [...], "meta": {...}, "goal": ..., ... }

base_seq is the core's high-water mark — the last_seq it believes the server holds. The contract, keyed on the server's ACTUAL last_seq:

• base_seq == last_seq → append all messages (the happy path).
• base_seq < last_seq → the leading last_seq - base_seq messages were already applied (a retry or a core that resumed from a stale cursor); drop them and append only the genuine tail. Fully-duplicate → no-op. This is what makes the push idempotent under retries.
• base_seq > last_seq → the core is AHEAD of us: we are missing messages it never delivered, so an append would splice a gap. Refuse with 409 need_full; the core falls back to a full /sync.

Only the fresh tail is handed to cache_and_broadcast_conversation (with base_seq), which appends it to the per-message rows without reading the stored body — the saving is on the wire AND in the database (this used to decode the whole history_json, ~70 ms and the entire blob per append, then rewrite it). Same conv_delta broadcast, figure rewrite and goal handling as the full sync.