Function resolve_delivery_tier 

fn resolve_delivery_tier(
    auth_via: ReactiveAuthVia,
    claimed: Option<&str>,
) -> String

Server-derived delivery_tier for the LAN-key case only — docs/specs/SPEC_JEKT_LAN_TIER_SIGNING_2026_08_15.md §3, revised after reagentx P0 on the implementing PR: an earlier version of this override also force-downgraded a “lan” claim to “host” whenever auth was via the full auth_key, reasoning that “nothing authenticated via the full key could have genuinely crossed the LAN boundary.” That’s false once same-host forwarding (Tier 2a/2b below in handle_reactive_inject) is considered: a jekt legitimately authenticated via lan_key at its FIRST hop, then relayed to a sibling channel/instance on this same machine, authenticates that SECOND hop with the sibling’s own full auth_key (not lan_key — that credential is peer-to-peer between distinct machines, never shared across same-host channels). Downgrading there silently discarded an already-detected LAN signature failure’s forced-sensitive escalation (lan_verified/reagent_verified are #[serde(skip_deserializing)], so they reset to None on every hop and must be free to re-derive from whatever delivery_tier the forward legitimately carries).

The actual gap this closes is narrower than “full auth_key can never claim lan”: a lan_key holder is the ONLY credential that can FORCE delivery_tier = "lan" regardless of what the body says (closing the original bypass — claim “host” instead to dodge LAN scrutiny entirely). A full-auth_key caller’s own claim (host/wan/lan) is otherwise trusted as-is: holding the full local key already grants complete control over this instance, so which tier it self-labels a request as grants nothing extra — at worst it triggers MORE verification (verify_lan_signature running), never less.

"channel" (SPEC_JEKT_CROSS_CHANNEL_TRUST_2026_09_02.md §D4) rides the same rule: it’s set by the FORWARDING instance on a same-host Tier 2a/2b hop and authenticates here with this instance’s full auth_key, so a full-key caller’s own "channel" claim is honoured as-is. Claiming it gains nothing — it only adds verify_cross_channel_signature on top of the unconditional verify_jekt_signature, never removes a check.