You are cfg-coder, a persistent coding agent working in ~/cfg. Your first task: investigate a sync bug in ~/cfg/lib/calendars.nix (specifically the sync-intervals-training.py script it embeds/references).

Context from Ava (the orchestrator) — what happened tonight:

• Ben had a workout in intervals.icu for tomorrow morning (2026-04-07 06:00, VirtualBike 1h15m Z2 ride, UID 0f9a5618…).
• It was correctly fetched from intervals.icu into ~/Calendars/intervals_training/ and recorded in vdirsyncer’s status DB for the training_to_shared pair.
• But it was NEVER on the shared CalDAV server (cal.bensima.com): 404 on PUT URL, missing from PROPFIND. Local shared mirror at ~/Calendars/bensima_shared/ben/ also missing it.
• Root cause (Ava’s read): vdirsyncer’s status DB has stale rows claiming the events are already synced (with hrefs and etags), but the remote actually doesn’t have them. So vdirsyncer says ‘Already normalized’ and skips on every sync.
• 58 status rows, 58 local files, only 56 actually on remote. Two ghosts: 0f9a5618… (tomorrow’s ride) and 90ff0e9f… (a Recovery Week NOTE event). For 90ff0e9f, hash_a ≠ hash_b in the status DB — vdirsyncer knows local differs from last upload but isn’t reconciling because the remote is gone.
• Immediate fix already applied: Ava did a direct curl PUT of the file to https://cal.bensima.com/shared/ben/0f9a5618….ics (got 201), then vdirsyncer sync pulled it down. Tomorrow’s workout is now on the calendar. So you do NOT need to fix tomorrow’s event — that’s already done.

What I need from you NOW (before any code changes):

1. Read ~/cfg/lib/calendars.nix and find the sync-intervals-training.py script.
2. Read the script and understand its current sync flow.
3. Inspect vdirsyncer’s status DB (somewhere under ~/.vdirsyncer/status/ — find it) and confirm Ava’s diagnosis: are there other ghost rows where hash_a ≠ hash_b or where the remote is missing files the status DB claims exist?
4. Look at the systemd unit / timer that runs this script (probably defined in calendars.nix or nearby) and the recent logs (journalctl –user -u -n 200 if a user unit, or sudo journalctl -u for system).
5. Form an opinion: was this a one-off transient failure (e.g. cal.bensima.com had a hiccup, vdirsyncer’s status didn’t notice) or is there a systemic bug in how the script + vdirsyncer interact?

Report back with:

• Your read of the script’s current architecture
• What you found in the vdirsyncer status DB (number of ghost rows, pattern)
• Recent systemd log evidence
• Your verdict: one-off vs systemic
• A recommended next step (do nothing / patch the script / promote the script to a proper subproject with tests)

Do NOT make any code changes yet. Just investigate and report. Once Ben sees your report we’ll decide direction together.

Proceed with the in-place reconciliation patch to sync-intervals-training.py. Approach: after the normal fetch/split step, list remote shared UIDs via PROPFIND, diff against local training UIDs, and directly PUT any missing UIDs to the shared CalDAV server (reusing existing credentials). As part of the first real run, fix the remaining ghost 90ff0e9f-c28c-4135-b19d-8817d1c15f8a. Keep it minimal—no subproject promotion yet. Commit in ~/cfg with a clear message and report back when done.