Wolts should own their memory loading — remove .claude/rules workaround

Context

Issue #97 (import gate blocking sessions) was fixed by symlinking wolt/memory/index.md into .claude/rules/memory-index.md. This bypasses Claude Code's import approval dialog because rules load without a trust gate.

But this is a workaround, not the right architecture. Wolt memory should be loaded by the wolt's own infrastructure, not by leaking into .claude/rules/. The .claude/ directory is Claude Code's config space — mixing wolt memory files in there creates coupling and confusion about who owns what.

What should happen

Wolts should manage their own memory loading through the platform — either via:

• A hook that injects memory content at session start (e.g. --append-system-prompt)
• A platform-level mechanism that feeds memory into the session context without relying on Claude Code's file-loading pipeline
• An InstructionsLoaded hook or similar that auto-approves known wolt paths

Current state

• .claude/rules/memory-index.md → symlink to ../../wolt/memory/index.md (workaround, merged for #97)
• @wolt/memory/index.md removed from CLAUDE.md
• Memory still loads correctly via the rules path, but it's in Claude Code's namespace instead of the wolt's

When to revisit

After the new onboard flow lands — that's a natural point to redesign how memory gets injected into sessions.

Start by reviewing issue #97, the .claude/rules/memory-index.md symlink, wolt/memory/index.md, CLAUDE.md, and the new onboard flow. Define the platform-owned memory injection approach, then verify that memory loads without the Claude Code rules workaround and that the symlink and related coupling are removed.