feat: repo-local .codex/supermemory.json for per-project container tags

[ayushsingh82]

Closes the per-project container tag half of #13. (The response_item transcript half is #37.)

Why

Right now the only way to override a project's container tag is globally, via projectContainerTag in ~/.codex/supermemory.json. That works fine if you live in one repo, but the issue's use case is a team running Codex, Claude Code and Hermes side by side against the same repo and wanting them all to share one memory bucket. You can't do that with a global setting — the value would need to change every time you switch checkouts, so anyone hopping between repos ends up fighting it.

What changed

getProjectTag() now also looks for a .codex/supermemory.json checked into the repo root. It's the same file name and the same field names as the global config — it just lives in the repo and only its tag fields are read:

• projectContainerTag — the project/repo container for this repo, and it takes precedence over everything else
• userContainerTag — a personal container that gets added to this repo's legacy read set

Full precedence order for the project tag, highest first:

<repo>/.codex/supermemory.json  →  .claude repo config  →  SUPERMEMORY_REPO_TAG
  →  .cursor repo config  →  global ~/.codex/supermemory.json  →  generated repo_<name>__<hash>

Whatever tag was active before you add the override stays in the read set (getProjectReadTags / getPersonalReadTags), so nothing you've already saved goes dark — no migration step. Discovery only happens at the git root, matching how the existing .claude/.supermemory-claude/config.json lookup already works.

Testing

npm run typecheck and npm test are green (69 tests). Added one test — repo-local .codex/supermemory.json overrides the tag and outranks the global config — that checks the repo-local tag beats a global projectContainerTag, the old global tag is still in projectReads, and a repo-local userContainerTag shows up in personalReads.