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.)