Phase 1-3: Add memory, skills, and improvement systems

- memory/: cross-session project memory with decisions, lessons, failures,
  architecture, and sessions categories. Each has format templates and
  lifecycle documentation.
- skills/: 12 reusable specialized methodologies (tdd, systematic-debugging,
  architecture-design, code-review, security-review, repository-analysis,
  failure-analysis, refactoring, test-analysis, incident-investigation,
  browser-automation, research). Each has frontmatter and methodology sections.
- improvements/: proposal-based improvement system requiring human approval.
- scripts/memory-lifecycle.sh: deterministic memory operations (recall, store,
  list, search, sessions, cleanup).
- scripts/test-memory-system.sh: 12 structural tests for all new systems.
- orchestrator.md: added Memory Recall stage, Learning and Memory Storage
  stage, Improvement Proposals workflow, memory/skills rules, and 3 new
  actions (A23-A27) to the action catalog. Updated behavioral acceptance test
  and state separation model.
- All 12 subagents: added Memory & Skills Awareness sections with recall
  and store instructions.
- docs/AGENT_ARCHITECTURE.md: documented memory, skills, and improvements
  systems (sections 12-14). Updated action count (27), state model, and
  remaining weaknesses.
- README.md: documented new systems, updated repository layout, added
  test-memory-system.sh documentation.

All 39 tests pass (16 architecture + 12 memory + 11 bootstrap).

improvements/README.md

@@ -0,0 +1,96 @@
+# Improvement Proposals
+
+Controlled self-improvement for the agent team. **No autonomous modification
+of core agent behavior without human approval.**
+
+## Structure
+
+```
+improvements/
+├── README.md              # This file
+├── pending/               # Proposals awaiting approval
+│   └── YYYY-MM-DD_<id>.md
+├── applied/               # Approved and implemented proposals
+│   └── YYYY-MM-DD_<id>.md
+└── rejected/              # Rejected proposals (kept for reference)
+    └── YYYY-MM-DD_<id>.md
+```
+
+## Proposal format
+
+```markdown
+# IMPROVEMENT-NNNN: <title>
+
+Date: YYYY-MM-DD
+Proposed by: <agent>
+Status: PENDING | APPROVED | REJECTED | APPLIED
+
+## Observed problem
+
+<what was noticed — repeated failure, inefficiency, missing capability>
+
+## Evidence
+
+<supporting evidence — failure records, metrics, examples>
+
+## Root cause
+
+<why this problem exists>
+
+## Proposed change
+
+<what specifically should change>
+
+## Affected agents/skills
+
+<which agents or skills would be modified>
+
+## Risks
+
+<what could go wrong>
+
+## Expected benefit
+
+<what improvement this would produce>
+
+## Verification plan
+
+<how to verify the change works as intended>
+
+## Approval
+
+- [ ] Human review
+- [ ] Impact assessment
+- [ ] Rollback plan
+```
+
+## How proposals are generated
+
+At the end of substantial work, the Orchestrator (or any agent) may create a
+proposal when it detects:
+
+- Repeated failures of the same type
+- Inefficient workflows that waste agent resources
+- Missing skills that would prevent a class of problems
+- Missing tests that would catch regressions
+- Documentation gaps that cause confusion
+- Architecture problems that slow down development
+- Poor agent delegation patterns
+
+## How proposals are processed
+
+1. Proposal created in `pending/`
+2. Orchestrator presents to user at a natural stopping point
+3. Human reviews and decides: APPROVE, REJECT, or MODIFY
+4. If approved: implement the change, move to `applied/`
+5. If rejected: move to `rejected/` with reason
+6. If modified: create a new proposal with the modification
+
+## Rules
+
+- **Never** modify core agent behavior without approval
+- **Never** modify the orchestrator's decision logic without approval
+- **Never** add new agents without approval
+- **Always** preserve backward compatibility
+- **Always** include a rollback plan
+- **Always** document what was changed and why