memory: file-path tests write the real default graph files and fail intermittently #4922

Found while building the pre-push gate (#4871, PR #4920). Not caused by that PR, which changes no server code.

Problem

src/memory/__tests__/file-path.test.ts failed once inside an npm run local:gate run and then passed seven consecutive re-runs of npm test -w src/memory with no change in between:

FAIL  __tests__/file-path.test.ts > ensureMemoryFilePath > without MEMORY_FILE_PATH environment variable > should use new file when both old and new files exist
AssertionError: expected false to be true
 ❯ __tests__/file-path.test.ts:158:29
    157|       expect(newFileExists).toBe(true);
    158|       expect(oldFileExists).toBe(true);

So src/memory/memory.json was gone by the time the test checked for it, although the test had just written it.

What is known, and what is not

• The tests in this file do not use a temporary directory. They write, migrate and delete the real default paths beside the source, src/memory/memory.json and src/memory/memory.jsonl, the same paths the server itself uses when MEMORY_FILE_PATH is unset.
• Anything else that calls ensureMemoryFilePath() with no MEMORY_FILE_PATH while this test runs will migrate memory.json away (rename to memory.jsonl) between the test's write and its assertion. Candidates: another test file in the same Vitest run (files run in parallel), or a memory server started from this checkout at that moment.
• The actual second writer was not identified. It reproduced once in roughly ten runs on macOS, Node 26.

Expected

The suite gives the same result every run. The file-path tests should not share state with anything else: point them at a per-test temporary directory (which needs ensureMemoryFilePath to take its base directory as a parameter, or an equivalent seam) instead of the package directory. Writing into the package directory also means a failed run can leave a memory.json or memory.jsonl behind in the working tree.

Notes

• AGENTS.md now forbids test retries (verify:no-test-retries), so this has to be fixed at the cause.
• Bugs, Coverage, and SDK Wave 1 Part 1: TypeScript servers: extensive unit tests + per-file 90% coverage gate #4854 rewrites the memory suite around an in-process harness and may absorb this; if it does, close this as part of that work.