feat(tools): scheduled USER-tree backup to a private repo (Linux scheduling)

[elhoim]

What

Adds LIFEOS/TOOLS/BackupUserData.ts, a scheduled job that mirrors the USER tree to its private GitHub repo, plus its README and a ConfigSystem.md section documenting it.

Why

ConfigSystem.md § Two-repo sync specifies the USER tree as its own private repo, kept in sync by ~/.claude/.git/hooks/pre-push. That trigger has two preconditions: the operator has to actually push the SYSTEM tree, and ~/.claude has to be a git repo. Neither holds on every install.

Where they don't hold, the USER tree — identity, DA identity, TELOS, projects, operational rules — has no off-machine copy at all. BackupBeforeUpgrade.sh doesn't close that gap either: it archives the SYSTEM tree and stores LIFEOS/USER as a bare symlink entry, deliberately.

This is the trigger-independent half of the same mechanism, not a replacement for the pre-push hook. On an install where the hook works, the two compose: the hook syncs on push, this syncs on a schedule.

The four refusals

Fail-closed throughout; each is a non-zero exit with a logged reason, never a silent skip.

1. Non-private remote. Visibility is re-checked on every run via gh repo view --json visibility,isPrivate. PUBLIC, an API error, an unparseable answer, or a missing gh all block the push. Per-run rather than once at setup, because a repo can be flipped public at any time.
2. The distribution repo. A remote whose repo is named LifeOS (any case) or whose owner is the upstream is rejected outright. USER data never goes near the public release path.
3. Secret material. Staged files are scanned for private-key blocks and GitHub / OpenAI / Anthropic / Slack / Google / AWS credentials and JWTs before the commit is created. A hit unstages everything and aborts.
4. A concurrent run. An exclusive lock means two overlapping invocations produce one commit, not a race. Locks older than 30 minutes are treated as stale.

When nothing changed it exits 0 with status=noop and creates no commit, so history records real change rather than the clock. One JSONL line per run lands in MEMORY/OBSERVABILITY/user-backup.jsonl.

Scheduling is Linux-only

Worth stating plainly, since it's the main limit on this PR. The tool itself is platform-neutral: it shells out to git and the GitHub CLI and nothing else. The schedule is a Linux user crontab, and that is the only scheduler it has been verified on. macOS operators should wrap the same command in a launchd agent (the shape LifeOS already uses for com.lifeos.pulse.plist) rather than assuming the crontab path works. The README and the doc section both say so.

Verification

Verified on Linux against a real private repo, not a fixture:

• Round-trip: wrote a marker file, ran, read it back from the remote via gh api; deleted it, ran, the same call returned 404.
• No-op path: two consecutive runs on an unchanged tree left HEAD identical and created no commit.
• Privacy gate: --check-visibility against a real public repo refused (exit 1); against a private one, passed.
• Distribution-repo guard: rejected both danielmiessler/LifeOS and a fork's LifeOS, accepted a normal user-data slug.
• Lock: two parallel runs on a dirty tree produced exactly one commit; the loser logged status=locked.
• Cron: proven end-to-end under the real cron daemon with a temporary every-minute entry, and separately under env -i with a stripped cron environment. No auth or PATH failures.

Not verified on macOS or with launchd — see above.

Notes for review

• No secrets are ever mirrored: .env*, key material, and the credentials directory are excluded, and credentials stay in ~/.claude/.env as they do today.
• Auth is expected to come from a git credential helper, so no token ever lands in a remote URL or a log line.
• LIFEOS_GH_BIN exists because the GitHub CLI may be a wrapper rather than a plain gh on PATH (e.g. when LifeOS runs as a system user distinct from the operator's own account).
• Happy to reshape this as a skill rather than a bare tool if that fits the distribution better.