A teammate's new lineup from a shared origin could land first; deleting a
lineup on a canvas that had not drawn it yet took the origin with it, and
the server accepted that delete. The teammate's link was left without its
origin, so hydration dropped the lineup for everyone while the chip said
synced.

- Server: with the new opt-in applyBatch flag checkLineupEndDeletes, an
  origin or landing delete fails with LINEUP_END_IN_USE while a live link
  on its page names it. Links deleted earlier in the batch are already
  tombstones. Clients without the flag (shipped builds, the web build that
  sends only checkLineupLinkEnds) keep today's behavior.
- Client: sends the flag; the outbox claims link deletes first and holds an
  origin or landing delete while a link delete on its page is still unsent
  (restart key order, batch cap, another client id, backoff).
- The refusal lands in attention with a plain message. Keep mine asks
  again; use theirs brings back the origin with the teammate's lineup.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>