Append Process Conversation

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.

History stays sourced from history_json during rollout, so this rebuilds the full array (old + fresh) and hands it to the same cache_and_broadcast_conversation the full sync uses — identical dual-write, conv_delta broadcast, figure rewrite and goal handling. The saving is on the WIRE (and the server's JSON parse), not yet the blob write (phase 4).