Fresh install leaves LIFEOS/MEMORY in the system tree, so every governed knowledge/idea write is refused

## Summary

On a clean v7.40.4 install, `~/.claude/LIFEOS/MEMORY/` is created as a **real directory inside the SYSTEM tree** and is never linked into the USER_DATA repo (`~/.config/LIFEOS/USER`). Because `MemorySystem.add()` enforces the system/user boundary with a realpath check, every governed `knowledge` and `idea` write is refused. The governed memory write path is dead on arrival for fresh installs.

## Reproduction

1. Clean macOS machine, no prior LifeOS install
2. `curl -fsSL https://ourlifeos.ai/install.sh | bash` (resolves v7.40.4)
3. Run the documented Setup phases: `DeployCore.ts --apply`, `ScaffoldUser.ts --apply`, `LinkUser.ts --apply`
4. Attempt any governed knowledge write:

```bash
bun ~/.claude/LIFEOS/TOOLS/Cortex.ts remember \
'{"type":"knowledge","entity_type":"research","name":"Test","content":"Test"}' \
--adapter claude --allow-write
```

Actual result:

```json
{"schema":"lifeos-cortex/v1","ok":false,"command":"remember","data":null,
"error":{"code":"governance_refused","message":"memory write refused at the system/user boundary:
resolved target ~/.claude/LIFEOS/MEMORY/KNOWLEDGE/Research/test.md is outside the USER_DATA repo
(~/.config/LIFEOS/USER) — personal data must never land in the system tree (SystemUserBoundary.md)"}}
```

## Root cause

- `Tools/DeployCore.ts` `scaffoldMemory()` creates the tree at `join(configRoot, "LIFEOS", "MEMORY")`, always the system tree
- Neither `Tools/ScaffoldUser.ts` nor `Tools/LinkUser.ts` references `MEMORY`
- `install/USER/` ships no `MEMORY` template
- So nothing ever creates the symlink the rest of the system already expects

The runtime **already assumes that symlink exists**. From `LIFEOS/TOOLS/lib/ForeignDataCheck.ts`, above `assertInsideUserData()`:

```
* Realpath-based on the deepest existing ancestor, so:
* - an intact `~/.claude/LIFEOS/USER` (or MEMORY) symlink resolves into
* ~/.config/LIFEOS/USER and passes;
```

And `DOCUMENTATION/SystemUserBoundary.md` documents the row for `~/.claude/LIFEOS/MEMORY/**` as `symlink → ~/.config/LIFEOS/USER/MEMORY/**, post-Phase-G.2, 2026-05-23`.

This most likely survived because installs predating Phase G.2 were migrated in place, so the clean-install path was never exercised.

## Impact

- `remember` fails for `knowledge` and `idea` types on every fresh install
- `memory` type still works, because it targets `USER/PRINCIPAL/` and `USER/DIGITAL_ASSISTANT/`, which `LinkUser` does symlink

## Verified workaround

```bash
mv ~/.claude/LIFEOS/MEMORY ~/.config/LIFEOS/USER/MEMORY
ln -s ~/.config/LIFEOS/USER/MEMORY ~/.claude/LIFEOS/MEMORY
```

After this, the identical `remember` call above succeeds and writes a proper `kb-v3` note plus its `tier-b-writes.jsonl` audit row.

## Suggested fix

Two shapes, and the choice is an architecture call:

1. Scaffold `MEMORY` under `install/USER/` in `ScaffoldUser`, then let `LinkUser` symlink it, matching how `USER` is handled today
2. Have `DeployCore.scaffoldMemory()` create the tree at `/MEMORY` and symlink `LIFEOS/MEMORY` to it, keeping memory scaffolding in one file

Option 1 is more consistent with the existing USER pattern; option 2 keeps DeployCore's "MEMORY scaffolded fresh at setup" contract in one place. Happy to send a PR once you indicate which shape you prefer.

## Environment

macOS 26.6 (arm64), bun 1.3.14, Claude Code, LifeOS v7.40.4 (commit `be9e8ef`)

Start by reproducing the clean-install sequence, then inspect Tools/DeployCore.ts, Tools/ScaffoldUser.ts, Tools/LinkUser.ts, and the install/USER template for MEMORY handling. Compare the chosen setup with Tools/lib/ForeignDataCheck.ts and DOCUMENTATION/SystemUserBoundary.md; done means a fresh install places MEMORY in USER_DATA, preserves the expected link, and allows the documented knowledge write.

Written by the indexing model from the issue text.