Memoize session-locator worktree walks

[germanescobar]

Problem

server/lib/session-locator.ts (introduced in PR #343, issue #339) exposes locateSessionById / locateSessionPath. Both functions call getProjectWorktrees, which reads + parses the entire /Users/germanescobar/Library/Application Support/Controller/worktrees.json and calls ensureMainInRegistry on every invocation.

Today these locators back four server entry points:

• the wakes consumer that's read on every scheduler tick
• the goal evaluator's active check
• the ID-only monitor route
• the ID-only goal route

Each entry point may call the locator more than once per request. As the registry grows (Controller users with many projects × many worktrees) the per-call JSON parse + project lookup becomes hot, especially on the wakes consumer's recurring tick.

Proposed approach

Introduce a small cache layer in server/lib/session-locator.ts (or in server/lib/worktrees.ts behind getProjectWorktrees):

• Keyed on (projectId, mtimeMs) so a registry write invalidates naturally
• Bound the cache size (e.g. last 64 lookups) so a long-running server can't grow unbounded
• Add a invalidateWorktreeCache() hook for tests that rewrite the fixture file

Keep getProjectWorktrees as a thin wrapper so existing call sites don't change.

Out of scope

• Switching to SQLite — too big a change for this iteration
• Changing the on-disk format

Acceptance

• Repeated calls to locateSessionById for the same (projectId, sessionId) within a single tick don't re-parse the registry
• A test under server/lib/__tests__/session-locator.test.ts exercises the cache (hit + miss after registry rewrite)
• Cache size is bounded

Related

• Same-session scheduled follow-ups, goal evaluator, and Monitor primitive (single PR, sub-issue of #219) #339 (feature)
• Same-session loop primitives: wake --delay, goal set, monitor start (#339) #343 (PR that shipped the locator)
• server/lib/session-locator.ts:1 — current implementation