fix(sync): make syncOnce cancellation race-safe

[marcus-pousette]

Problem

The inbound controller must stop an in-flight SyncPeer.syncOnce when a target times out, disconnects, or is removed. Merely stopping the caller's wait lets responder work continue and can let an asynchronous Hello handler recreate state after cleanup.

This is the protocol prerequisite for #138. It contains no controller or playground code.

Fix

• Add AbortSignal support to syncOnce and reuse it for subscription reconciliation.
• Check cancellation across backend reads, auth hooks, RIBLT work, sends, and direct-send batches.
• Delete the initiator session immediately and send best-effort remote cleanup after Hello was transmitted.
• Register responder-side per-filter abort controllers before the first asynchronous Hello step.
• Recheck cancellation before creating sessions, recording upload acknowledgements, or sending each batch.
• Cancel superseded work for the same transport/filter without affecting other filters.

Clean integration with #191

The port keeps #191's exchangeId, pendingHelloExchanges, transport-owned state, and capability lease checks. Cancellation cleanup is addressed by filterId; it does not restore the old global Hello waiter or misuse direction-owned exchange IDs.

Semantics and fast paths

• Calls without a signal keep the direct-send and RIBLT paths without cancellation listeners.
• Cancellation cannot recall valid operations already transmitted or committed; it prevents later work and state resurrection.
• Cancellation state is scoped by transport and filter and removed when Hello handling finishes.

Size and verification

• Incremental diff: 3 files, +369/-69.
• Protocol TypeScript build passes.
• Full protocol suite: 58/58.
• Regressions cover pre-abort, delayed responder storage, post-cancel batches, session cleanup, and listener cleanup.