fix(listener): expose agent MemFS to mod callbacks

[overlord-letta]

Summary

• give listener mod callbacks the active agent’s MemFS status and scoped memory root
• preserve that context across turn events, tools, permissions, commands, model/toolset updates, and approval recovery
• keep disabled agents and concurrent agents isolated without using process-global MEMORY_DIR

Problem

The listener syncs an agent’s MemFS before loading mods, but callback context construction discarded that state. buildModInvocationContext() then supplied { enabled: false, memoryDir: null }, so MemFS-aware mods used machine-local fallback storage.

Reported in #3669.

Before / after

Before: a MemFS-enabled agent invoked through a listener gave global and package mods a disabled MemFS context.

After: each callback resolves the active agent’s current MemFS setting and exact scoped root. Disabled and no-agent contexts remain disabled.

Scope and risk

This does not change MemFS sync, storage, or commit behavior. It adds synchronous context metadata after the existing agent sync step. Context stays agent-scoped when one listener serves several agents.

Test plan

• Direct listener-context regression for two enabled agents, one disabled agent, and no active agent
• The same context test on the parent returns disabled/null for an enabled agent; it passes here with distinct scoped roots
• bun test src/websocket/listener/mod-adapter.test.ts src/websocket/listener/agent-mod-isolation.test.ts
• bun run check
• git diff --check

Overlord (agent-c2adbf5c-8419-4211-8cd8-3740db164974)

👾 Generated with Letta Code