feat: replace megamemory with markdown-based memory system

Remove the megamemory MCP knowledge graph and replace with plain
markdown files in .memory/ for tracking plans, research, knowledge,
and implementation state. This enables collaboration across people
and agentic coding tools (Claude Code, Copilot, Cursor, etc.).

Changes:
- Remove megamemory MCP from opencode.jsonc
- Delete tool/megamemory.ts and .megamemory/ database
- Rewrite all 25 config files to use .memory/ markdown files
- Add cross-tool instruction file awareness (AGENTS.md, CLAUDE.md,
  copilot-instructions.md, .cursorrules)
- Update save-memory, bootstrap-memory, status commands for md workflow
- Update all agent files, skills, and commands consistently

.config/opencode/commands/bootstrap-memory.md

@@ -1,47 +1,86 @@
-# Bootstrap Project Knowledge Graph
+# Bootstrap Project Memory Files
 
-RUN { git ls-files; git ls-files --others --exclude-standard; } 2>/dev/null | sort -u | xargs wc -l 2>/dev/null | sort -rn | head -150
+RUN { git ls-files; git ls-files --others --exclude-standard; } 2>/dev/null | sort -u
 READ README.md
 
-You are bootstrapping the megamemory knowledge graph for this project.
+You are bootstrapping `.memory/` files for this project.
 
-Your job is to understand the codebase and record its core concepts, architecture,
-and patterns as knowledge graph nodes. The file listing above is sorted by line
-count — the biggest files are where the core logic lives.
+Your job is to inspect the codebase and create an initial memory baseline in plain
+markdown files. Capture architecture, core modules, conventions, and key decisions
+so future sessions can resume quickly.
 
-## Step 1: Check existing graph
+## Step 1: Create `.memory/` structure
 
-Call `megamemory:list_roots` to see what's already recorded. If the graph has
-good coverage, report what's there and ask if I want to fill in specific areas.
+Create (if missing):
 
-## Step 2: Identify major modules
+```
+.memory/
+  knowledge.md
+  decisions.md
+  plans/
+  research/
+```
 
-From the file listing and README, identify the top-level systems in this project.
-Think in terms of:
-- What does this project DO? (features)
-- What are the distinct subsystems? (modules)
-- How is it structured? (patterns, decisions)
+`.memory/` is tracked in git.
 
-## Step 3: Read and create root concepts
+## Step 2: Inspect project structure
 
-For each major module, read its key files to understand what it does. Then call
-`megamemory:create_concept` with a specific, detailed summary. Include parameter
-names, defaults, file paths, and behavior details — not vague descriptions.
+Run `git ls-files` to understand the project layout, then read `README.md` and
+the highest-signal files for architecture and conventions.
 
-## Step 4: Create children for important sub-components
+Identify:
+- What the project does (primary capabilities)
+- Core modules/subsystems and responsibilities
+- Key patterns/conventions (naming, layering, testing, config)
 
-For substantial modules, create child concepts for key pieces. Stay max 2 levels
-deep. Focus on things a developer would need to know when working in that area.
+## Step 3: Write initial `knowledge.md`
 
-## Step 5: Link related concepts
+Populate `.memory/knowledge.md` with:
+- Project purpose and scope
+- Architecture overview
+- Key modules with file paths
+- Important implementation patterns/conventions
 
-Connect concepts that interact across boundaries using `megamemory:link`.
-Focus on meaningful relationships: depends_on, calls, connects_to, implements,
-configured_by.
+Use markdown sections with max 2 heading levels.
+
+## Step 4: Seed `decisions.md`
+
+Populate `.memory/decisions.md` with any clear, durable decisions found in docs
+or code patterns (for example: stack choices, testing strategy, architectural
+constraints). Include rationale when known.
+
+## Step 5: Initialize plans/research folders
+
+- If active in-progress work is discoverable, create `.memory/plans/<feature>.md`
+  with scope, tasks, and acceptance criteria.
+- If research artifacts are discovered, create `.memory/research/<topic>.md`
+  with findings and references.
+
+## Step 6: Create/update cross-tool instruction files
+
+After `.memory/knowledge.md` is populated, use it as the source of truth to
+create or update all cross-tool instruction files:
+
+- `AGENTS.md`
+- `CLAUDE.md`
+- `.github/copilot-instructions.md`
+- `.cursorrules`
+
+Each file should include the same core project guidance:
+- project overview and purpose
+- tech stack
+- architecture summary
+- coding conventions/patterns
+- build/test/lint commands
+- project structure overview
+
+If any of these files already exist, preserve existing project-specific content
+and merge in new knowledge instead of overwriting wholesale.
 
 ## Guidelines
 
-- Be specific. "Handles auth" is useless. "JWT auth with RS256, tokens from
-  /auth/login, validated in middleware, refresh tokens in Redis with 7d TTL" is useful.
-- Focus on the top 10-15 most important concepts first. The graph grows over time.
-- Don't document trivial things. If it's obvious from the file name, skip it.
+- Be specific with file paths, APIs, parameters, and behavioral details.
+- Keep sections concise and scannable.
+- Prefer durable knowledge over transient status notes.
+- Add markdown cross-references between related entries (for example,
+  knowledge entries linking to decisions).