CourierRegistry

Per-peer courier orchestration, owned by CommsService.

Declared in src/libs/libcomms/comms/couriers/CourierRegistry.hpp.

Detailed description

Why this is not on Node

§ACO-4 cuts W6 cluster A into "CommsService + an internal CourierRegistry", and §AC-3.1 says a subsystem takes its real dependencies rather than the object that composes them. This class takes a Comms. It never names Node.

The lazy creation below lived on Node as Node::blobCourierForPeer() — a public accessor handing out a courier, which is the getter surface §AC-3 retires. Nothing about the logic needed a node: Comms already owns the courier registry itself (mCouriersByID, registerCourier, courierByID) and already holds the keystore and the address book the courier is built from. The node was only ever the object that happened to have all three in scope.

Why the created courier is announced by signal

The receive-side NID-transfer dispatcher lives in libnode and must subscribe to each new courier (§DM-P4). Calling it from here would point libcomms at libnode and reintroduce the upward dependency this move removes. The signal inverts it: the registry announces, and whoever owns the dispatcher connects.