feat(pulse): schedule data-freshness daemons via Pulse cron so they run on Linux

[elhoim]

Problem

Three data-freshness daemons ship with macOS-only launchd installers and no other install path:

Daemon	Installer	What it keeps fresh
DerivedSync	TOOLS/InstallDerivedSync.ts	USER-tree derivatives (e.g. PRINCIPAL_TELOS.md) when their sources change
UsageAggregator	TOOLS/InstallUsageAggregator.ts	per-day Claude Code usage store that Pulse's cost views read
WorkSweep	TOOLS/InstallWorkSweep.ts	Work capture surfaces → GitHub issues

All three use ~/Library/LaunchAgents + launchctl, so on Linux they never run and their outputs silently drift. (Observed on a headless Linux box: PRINCIPAL_TELOS.md and 22 other derivatives were stale because DerivedSync had never fired.)

Fix

Schedule them through Pulse's built-in cron heartbeat — the same cross-platform move as the Conduit jobs — by adding three [[job]] entries to the template PULSE.toml:

• derived-sync — every 30 min
• usage-aggregator — nightly 03:30
• work-sweep — hourly (self-disables cleanly until USER/WORK/work_repo.json is configured)

Commands run with cwd = PULSE/, hence the ../TOOLS/… paths. Pulse's existing missing-script preflight and consecutive-failure ceiling disable any job that can't run on a given install, so this is safe by construction.

Verified (headless Linux)

All three run cleanly via --dry-run and then live under Pulse's cron:

• DerivedSync — regenerated the drifted derivatives; re-run reports 0 drift.
• UsageAggregator — rolled up real per-day usage.
• WorkSweep — self-disabled cleanly (no work repo configured), exit 0.

Note for macOS users

If you also bootstrapped the launchd agents, disable one of the two paths to avoid double-scheduling. The jobs are idempotent, but running each twice is wasteful. Longer term these launchd installers can be retired in favor of the Pulse-cron path.

(Depends conceptually on #1652, which fixes a DeriveDenyHashes crash that would otherwise abort every derived-sync run.)

[danielmiessler]

Declining this and #1650 together, since they're one decision.

Your diagnosis is right: those installers are launchd-only, so the jobs genuinely don't run on Linux. But the fix routes scheduling for jobs that currently run under launchd through Pulse cron, and on a macOS install that risks two schedulers owning the same job. I prototyped a single-owner guard to make it safe and then decided against the whole direction — adding a guard to protect the primary machine's scheduling from a change that only benefits a platform we can't test is the wrong trade.

The standing rule here is that platform support should be as universal as possible but strictly additive: a second backend beside the first, never a change to the path the primary install already runs. #1692 (systemd --user beside launchd for WorkSweep) is exactly that shape and landed today.

If you want to take these two again in that shape — a Linux-only backend inside each installer, launchd untouched — that would land.