Support installing LifeOS into an isolated `CLAUDE_CONFIG_DIR`

## Problem

LifeOS installs into `~/.claude` — the user's primary Claude Code config. Across `LifeOS/install/`, **391 files hardcode `~/.claude` / `$HOME/.claude` (1,780 occurrences)**, so the install root isn't really a parameter.

That means you can't try LifeOS without adopting it, can't develop it without mutating the assistant you're currently using, and can't run two configurations (work vs. personal, stable vs. dev, two principals on one machine) — which is a shame for a system that's fundamentally about per-principal identity.

The failure mode is quiet, too. `USER/CONFIG/LIFEOS_CONFIG.toml` ships `user_dir = "~/.claude/LIFEOS/USER"`. Move the config root without rewriting that and `LifeosConfig` still loads fine — it just resolves to a path that doesn't exist, `identity.ts` reads no frontmatter, and the install silently reports its DA as "LifeOS" and its principal as "User". Nothing throws, so the `try/catch` fallback in `paiUserDir()` never fires.

## Fix

Claude Code already supports this — it reads everything from `CLAUDE_CONFIG_DIR`:

```bash
claude # normal setup, ~/.claude
CLAUDE_CONFIG_DIR=~/.claude-lifeos claude # isolated LifeOS
```

```bash
# ~/.zshrc
alias lifeos='CLAUDE_CONFIG_DIR="$HOME/.claude-lifeos" claude'
```

So the ask is just: **stop hardcoding the path, read the config root, default it to `~/.claude`.** No behavior change for existing users, and it can land incrementally by area (`LIFEOS/`, `skills/`, `hooks/`, `agents/`, `USER/`) rather than as one huge diff.

Happy to do that work and split it into reviewable chunks if you want it.

## Context

I maintain [claude-playbooks](https://github.com/ramazanpolat/claude-playbooks) — a playbook is just an isolated Claude Code instance, i.e. a directory you point `CLAUDE_CONFIG_DIR` at.

I'm currently porting LifeOS to run as one, in [`ramazanpolat/LifeOS@claude/playbook-install`](https://github.com/ramazanpolat/LifeOS/tree/claude/playbook-install): the checkout root *is* the config root, and a deployer materializes `LifeOS/install/` into it, rewriting the hardcoded paths on the way. It works, and it's running my daily instance — but the rewrite pass only exists because the paths aren't parameters. If upstream took the change above, that layer would mostly disappear.

Not asking you to adopt any of my code — just checking whether path-parameterization is something you'd take into account.

Begin by auditing the hardcoded paths under LifeOS/install/, especially the LIFEOS/, skills/, hooks/, agents/, and USER/ areas. Read USER/CONFIG/LIFEOS_CONFIG.toml, identity.ts, and paiUserDir() first; done means installation resolves its root from CLAUDE_CONFIG_DIR while defaulting to ~/.claude and identity/config paths remain valid.

Written by the indexing model from the issue text.