fix(pi-fff): persist fff-mode across /reload and session resume

[monotykamary]

Problem

/fff-mode override did nothing useful — the mode was only stored in an in-memory variable (currentMode) that was lost on /reload and session restart. Tool names (ffgrep/fffind vs grep/find) were computed once at factory init as a const, so even a same-session mode change had no effect on registered tool names.

Solution

pi.appendEntry("fff-mode", { mode }) for session-level persistence. The mode is saved to the session file (does NOT pollute LLM context) and restored on session_start. This handles:

• Same-session mode changes: currentMode is updated in memory, affecting shouldEnableMentions() immediately
• Session resume after process restart: session_start restores the mode from session entries
• /reload: currentMode is restored by session_start, but tool names are determined by the user-configured flag/env at factory init time — the /fff-mode command notifies the user that a tool name change requires /reload

Changes

• /fff-mode command handler: Calls pi.appendEntry("fff-mode", { mode }) after mode change. Updated notice from "requires restart" → "requires /reload".
• session_start handler: Restores mode from session entries (defensive: skips if sessionManager unavailable).
• Test fixture: Added appendEntry mock to createPi().

Why not dynamic override tool registration?

I considered extracting tool definitions into factory functions for runtime registration, but:

• Tool registration blocks are ~200 lines of complex closures — large, risky refactor
• pi.setActiveTools() replaces the entire active set, fragile to compose with other extensions
• You cannot unregister tools, so switching FROM override would leave orphans

The /reload path is clean and already what the command was telling users to do.

Test plan

• bun test packages/pi-fff/test/ — all 17 tests pass
• Manual: /fff-mode override → notify shows /reload required → /reload → mode persists in memory
• Manual: Set override → close pi → reopen with session resume → mode persists

---

v2 update: Removed process.env.PI_FFF_MODE mutations — env vars are a user-set config layer, not meant for runtime mutation. pi.appendEntry is the sole persistence mechanism.

[dmtrKovalenko]

I don't think you need to set the env variables, they meant to be used as a persistent configuration layer

did you find that it doesn't work without env var? it should be safe to delete it

[monotykamary]

Just fixed it. It was a premature mutation to prevent the /reload from taking the env variable. Luckily, session_start and the appended entry should restore the currentMode just fine alone.