Function verify_cross_channel_signature 

pub(super) fn verify_cross_channel_signature(
    state: &AppState,
    req: &mut InjectionRequest,
)

Cross-channel (same machine, different AgentMux instance) per-agent Ed25519 signature verification — docs/specs/SPEC_JEKT_CROSS_CHANNEL_TRUST_2026_09_02.md §D2, Phase B.

Mirrors verify_lan_signature’s structure but resolves the claimed sender’s public key from the host-global shared registry (AgentEntry::jekt_public_key, published at registration by whichever instance actually spawned that agent — §D1) instead of a LAN round trip. A local file read, so this is synchronous and has none of the LAN lookup’s rate-limiter Skipped hazard.

Only meaningful for delivery_tier == "channel" — the label a same-host forward now carries (§D4, set by the forwarding instance in handle_reactive_inject’s Tier 2a/2b). Off that tier the field stays None, same scoping as lan_verified.

Ordering guarantee (§D2 step 2): a claimed sender THIS instance holds an HMAC key for is a same-instance agent, and verify_jekt_signature owns it entirely — this function returns without touching channel_verified, so the two verifiers can never disagree about one message.

Outcomes, all three-state like its siblings:

• None — no shared-registry entry for the claimed sender anywhere (a genuine bridge, or an agent that never registered), OR every entry found has an empty jekt_public_key (written before Phase A shipped — “cannot check,” never “failed the check,” §6). Nothing to verify against; not a red flag on its own.
• Some(true) — channel_sig present, fresh, and verified against the published key of ANY of that agent’s entries (one agent name can legitimately be live in several channels at once — §D2 step 5).
• Some(false) — a published key WAS found but the signature was missing, stale, or wrong. The §D3 red flag; not escalated in Phase B (see InjectionRequest::channel_verified’s doc comment).