Item 55: The `Due` connection: token, docket item, certified response

Due is untouched by the certificate and reason-state layers, and deliberately: the reason state supplies no burden calculus and must not, since hardwiring Due into the dependency graph was the failure the reason-state dispatch flagged. The record generates it, through due tokens and docket coverage.

The item is one closed loop on one fixture: a standing rule fires and mints a due token, the token is docketed as an identity-bearing task, a response is performed, and a service certification discharges it against the task's pinned specification — with the reason-state queries carrying the dependency at each step.

Deliverable shape: test-supported — one fixture running end to end, with the negative controls that distinguish discharge from expiry and from mooting. Acceptance check: the fixture runs in the legitimacy line's runner, and a variant that skips docketing leaves a visible coverage debt rather than passing. Context: .../2026-08-23-transition-certificates/MEMO.md §6 (iii), §8; .../2026-08-23-afoundational-inquiry/MEMO.md; .../2026-08-23-certified-interactive-service/SERVICEABILITY.md. Consumed by: the round that closes the response-learning loop, which needs a Due its learner can be answerable to.