ops2 events

A reverse ops2.delivered sets return_parcels.carrier_confirmed_back_at and nothing else. The credit waits for physically_received_at, which only a human dock scan or an RFID gate read can set, and a CHECK enforces that a parcel with units_received > 0 must carry that timestamp.

The reason is a live class in ops2. A provisional system_auto / pending_physical_scan placeholder gets promoted by the silent-RTO sweep to a terminal delivery_status='ReturnedToSender' with delivered_at=NULL and a synthetic source='warehouse' event. The poller then excludes terminal rows, so the carrier's real Delivered scan never lands. Roughly 197 production rows say returned about parcels that reached the customer, and 5 of 7 sampled AWBs were live-verified as carrier-Delivered.

If i3 credited on a carrier string, every one of those 197 would become a phantom unit in sellable.

ops2's refulfil modal offers seven reasons. Four of them mean the new AWB is a leg of an existing reverse case and must claim against its anchor rather than deduct fresh: The three that do not link post nothing: the units already left on the original AWB and are still in IN_TRANSIT_CUSTOMER. Today ops2's api_refulfill has no inventory step of any kind, forward or reverse, so all seven reasons are inventory-silent and the four that should link are exactly where the 111 double-deductions come from.

The two unmatched rows in the stream are the two non-linking reasons arriving without a resolvable anchor, which is correct behaviour surfaced as a queue rather than a silent skip.

ops2's emit() iterates _matching_subscribers and writes a DLQ row per match. With no registered subscriber it writes nothing and returns 0. An unknown event type also returns 0, with a comment saying "we do not raise so a typo does not nuke the user's write".

Two consequences for this bridge:

1. Events fired while i3 is not yet subscribed are gone, with no backfill path. The v2 mockup's banner promised "queued events will backfill on resume"; that promise cannot be kept against the current implementation. Module 04's task T-04.21 is the outbox PR that fixes it, and it touches the ops2 poller, which deploys in lockstep with web.

2. The subscription must be registered before the first topic is switched on, not after. Task T-08.22 exists purely to enforce that ordering, because the failure is silent on both sides: ops2 logs nothing and i3 simply sees no traffic.

Today the dispatch scan decides its own exclusion in iwms/bridges/ops2_dispatch.py::_decide, from a free-text order tag plus a prior-dispatch lookup, once per parcel rather than once per line. A tag becomes evidence with confidence 0.60, beaten by an operator link at 1.00, a variant swap at 0.85 and a line-gap at 0.90, and beaten outright by a CSD claim. It is no longer a decision.