Support hook-based memory capture when the CCE project is an additional directory, not the session's primary cwd (multi-root Claude Code workspaces)

[cangma]

Use case

Claude Code supports sessions with one primary working directory plus
"additional directories" — e.g. a session rooted at a personal notes repo,
with one or more actual code repos added as additional directories. This is
a common pattern when someone works across several repos from one
long-running session (in our case: a notes/docs repo as primary, with a
separate code repo — where CCE is initialized — added as an additional
directory).

Problem

The 5 lifecycle hooks installed by cce init (cce_hook.cmd/cce_hook.sh)
resolve which project's memory server to talk to via
basename(process cwd). In a session like the one above, the hook process's
cwd is the primary directory (the notes repo), not the additional directory
where the actual CCE-initialized project lives — so basename never matches
any ~/.cce/projects/<name>/serve.port, and every hook silently no-ops.
Net effect: cross-session memory (record_decision et al.) never gets
ambient/automatic capture in this setup, even though context_search itself
works fine (registered at user scope in .mcp.json, which isn't tied to cwd).

This is conceptually similar to what came up in #108 (worktrees) — project
identity resolution based on a naive directory-name assumption breaks once
the 1:1 "cwd == project" assumption doesn't hold.

Ask

Would it be feasible for hook-based capture to resolve the target project
from something other than (or in addition to) the hook process's own cwd —
e.g.:

• an explicit project pointer (env var, or a small marker file) settable
  once per machine/session, or
• inspecting the hook JSON payload's tool-call file paths (many hook events
  include the touched file's path) to infer which known CCE project a given
  event actually belongs to, when it doesn't match cwd

Happy to test against our setup if there's an experimental flag or config
for this.