claude: back up custom skills, memory, and settings with symlink pattern

The ~/.claude/ directory was previously local-only — a machine wipe
would have lost the accumulated memory, custom skills, and settings.
This commit moves the durable parts into dotfiles with the same
symlink-to-home pattern used for CLAUDE.md, PENDING.md, REVIEWED.md,
and L2-BOOTSTRAP.md.

Preserved (symlinked from ~/.claude/* into here):
  skills/audit/              — thinking-folder drift scanner
  skills/symmetria/          — practice-of-return discipline
  skills/vault-update-people/ — Obsidian People-file maintainer
  skills/wake-up/            — session restoration
  skills/wrap-up/            — session state capture
  memory/                    — 55+ memory files (MEMORY.md, sessions,
                               ledgers, project state, feedback, etc.)
  settings/settings.json     — user preferences (hooks, flags, no secrets)

Deliberately NOT backed up:
  settings.local.json   — contains operational secrets (HF_TOKEN,
                           SSH password in expect scripts); by naming
                           convention, *.local.* is not synced.
                           Needs separate review and probable rotation.
  sessions/, history.jsonl, caches, telemetry — ephemeral
  plugins/, marketplace skills and agents — reinstallable

The working copies at ~/.claude/skills/* and
~/.claude/projects/-Users-davidglidden/memory are symlinks into this
directory, so every write flows here automatically. install.sh
recreates the symlinks on a fresh machine.

FOLLOW-ON (flagged, not in this commit):
  settings.local.json contains a HuggingFace token and an SSH password
  as plaintext strings inside allowed Bash command patterns. These
  should be rotated and moved to secure storage (keychain / pass /
  env file outside the settings file).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

claude/memory/feedback-dependency-chains.md

@@ -0,0 +1,11 @@
+---
+name: feedback-dependency-chains
+description: Always question dependency chains — check which specific phases are actually blocked, not just the chain as stated
+type: feedback
+---
+
+Never accept a dependency chain at face value. Always ask: which specific phases or tasks are actually blocked, and which can proceed independently?
+
+**Why:** The chain "L1 reliable → Chamber testable → L2 formalizable" was accepted for 3 weeks without questioning that Chamber Phase 1-2 and L2 governance were independent of L1. This cost David weeks of governance time on L1 debugging.
+
+**How to apply:** When a blocking dependency is stated, decompose it. Check whether sub-phases, sub-tasks, or parallel tracks exist that are not actually blocked. Surface these immediately. The contamination problem predicts that the executor will accept stated blockages rather than challenge them.