Hub must not return a success that asserts more than it verified (ok:true vs delivered)

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: to=pm:<aro> with no electable PM and a "known" aro silently 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 proof: aro:ayudarg holds 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 (Elazar, the emitter) are both non-electable, so it can never elect and never drains. Caller scrp-applog-ayudarg has received ok:true for days for messages nobody will read. (b) VERIFIED: 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, passed on as-is: roster membership vs online liveness conflated in the same area. Design constraint: do not merely rename queued:true. Decide what a caller should receive when nothing was delivered and nothing is guaranteed to be, and bound the queue - no cap and no TTL is how 342 became invisible. Diagnosis+design+diff = coder-llmmsgsrv-cc; PM gates+applies+deploys (mem:hub-work-division). Staffing half of ayudarg (is the project alive) is a separate question, already with Elazar.