Function handle_muxspect_verify_sender 

pub async fn handle_muxspect_verify_sender(
    __arg0: State<AppState>,
    __arg1: Query<MuxspectVerifySenderQuery>,
) -> impl IntoResponse

GET /api/v1/muxspect/verify-sender?name=X — answers “is an agent named X currently registered, and via what tier” in one call, so an agent that just received a [JEKT:FROM=X ...] marker doesn’t have to fall back to manual filesystem/process archaeology to sanity-check the claimed sender exists at all. See VerifySenderVerdict’s doc comment for the important caveat this is NOT the JEKT protocol’s own cryptographic sender verification. See docs/retro/RETRO_JEKT_CROSS_ CHANNEL_TRUST_SELF_DECLARED_2026_08_21.md for the incident this closes the liveness-lookup gap on, and docs/specs/SPEC_MUXSPECT_VERIFY_ SENDER_2026_08_21.md for the full design.

Composes the same four sources handle_discovery (GET /agentmux/discovery) already aggregates — host-tier AgentRegistration, the host-global cross-channel shared registry, LAN mDNS peers, and the WAN cloud subscriber — into a verdict instead of raw discovery data. Always 200 (matching list/dock/describe’s own convention of encoding “nothing found” in the body rather than the HTTP status — a not_found verdict is a legitimate query result, not a caller error) — apiGet’s fail-on-non-2xx contract in muxspect.mjs would otherwise turn a normal “no such sender” answer into a hard CLI failure.