Function resolve_agent_id_for_jekt 

fn resolve_agent_id_for_jekt(
    block_meta: &HashMap<String, Value>,
) -> Option<String>

Resolve the effective AGENTMUX_AGENT_ID for jekt auto-registration from a block’s own spawn metadata — both the canonical key and the legacy WAVEMUX_AGENT_ID alias, checked in the SAME block-scoped cmd:env map. Deliberately does NOT fall back to std::env::var for either key: that reads THIS SRV PROCESS’s own environment, shared by every block/pane this instance spawns — reintroducing exactly the same collision as the global-settings fallback below (#2694). Nor does it fall back to the global settings’ cmd_env.AGENTMUX_AGENT_ID: that value is shared across every pane in the instance/channel, so a pane spawned without its own explicit per-block ID would silently inherit whatever another pane happened to configure there — and register_agent_with_nonce unconditionally evicts whoever previously held that agent_key, so the second such pane to register silently steals the first’s jekt identity (same-host cross-instance jekt misdelivery). See cmd_env_overrides below (its settings.cmd_env loop) for the matching fix that keeps this global value out of the pane’s OWN environment too — otherwise a pane could still pick it up via OSC 16162 and re-register through the frontend’s /agentmux/reactive/register path instead, even with THIS function never reading it directly. A pane with no block-scoped identity is simply not jekt-registered, matching persistent/mod.rs’s muxbus_agent_id_from_env, which never had either fallback.