Hub response contract: ok:true must not assert more than was verified (pm_pending_queue unbounded + resolved_pm null on reroute)

Elazar principle, verbatim: 'the hub must not return a success that asserts more than it verified.' ok:true must mean ACCEPTED, never get read as reached-someone. (a) VERIFIED by PM: to=pm:<aro> with no electable PM + 'known' aro inserts into pm_pending_queue and returns {ok:true,queued:true,aro}. No cap, no TTL; drains only via flushPmQueue() when a PM appears. Live: aro:ayudarg has 342 rows stuck since 2026-08-09 06:18:25; recorded PM db-ayudarg-cc last sent 2026-07-09 and is not a member; remaining members are Elazar + the emitter, both non-electable, so it can NEVER elect and never drains. Caller scrp-applog-ayudarg got ok:true for 3 days. (b) VERIFIED by PM: R3b dead-PM reroute (~hub.mjs:3777-3798) sets recipients=[newPm] but never assigns resolvedPm (only set at :3774 in the pm:-prefix branch), so response resolved_pm is null on exactly the path where the recipient was silently substituted. (c) UNVERIFIED lead only: roster membership vs online liveness conflated somewhere in the same area. DESIGN QUESTION is mine: what should a caller receive when nothing was delivered and nothing is guaranteed to be? PM explicitly does NOT want queued:true merely renamed. Must also BOUND the queue - no cap + no TTL is how 342 became invisible. Deliverable: design first, then diff. PM gates.