fix(pulse): stop setup.ts clobbering an existing PULSE.toml

[elhoim]

The problem

PULSE/setup.ts unconditionally overwrites PULSE.toml with a three-job template. There is no existence check and no backup, so running the documented bun run setup.ts on an already-configured install destroys the daemon's config of record in a single call.

What goes: [voice], [telegram], [imessage], [observability] including the server port, every [notifications.*] routing rule and threshold, [hooks] blocked_skills, [work], [bunker], [syslog], [local_intelligence], [telos], the whole [da] block (heartbeat, diary and growth schedules, cost ceiling), and every [[job]] cron entry — replaced by [worker] plus three samples.

Most personal installs are not git repositories, so this is unrecoverable.

The fix is suggested by the surrounding code: the .env write about twenty lines below already checks for existence and appends rather than clobbering. The two branches of the same function disagreed with each other.

The fix

Every config write now goes through one writeConfigPreserving helper:

• absent → created, so first-run onboarding is unchanged
• present → preserved untouched, and the run says so
• --force → replaced, but only after announcing it and copying the existing file aside as <file>.backup-<timestamp>

Create-only is the right default here rather than a merge: a partial merge of a TOML the operator has hand-tuned produces a config that is neither theirs nor the template's, and silently reintroducing sample jobs into a live scheduler is its own failure. Preserve-and-tell leaves the operator in control, and --force plus a backup covers the genuine reset case.

The launch agent write is guarded the same way, for the same reason.

Tests

test/pulse/setup.test.ts, 9 cases: a fresh path is created, an existing config survives byte-identical, --force replaces it, the backup holds the original contents, and the announcement fires before anything on disk changes.

9 pass
0 fail
26 expect() calls

Separately verified against the exported helper with an independent case set, including one the unit tests do not cover: repeated --force runs keep distinct backups rather than overwriting the previous one.

✓ absent → created
✓ present → preserved
✓ preserved: real job survived
✓ preserved: template not leaked in
✓ force → overwritten
✓ force announced before the write
✓ force: backup holds the ORIGINAL
✓ repeat force keeps distinct backups — 2 backup(s)

Notes

No behaviour change for a fresh install. The only way to lose config now is to pass --force, which prints the backup path first.