Sync: tracking issue and v0.14.0 release triage

Start by reading the linked aw-server-rust issues and pull requests, especially #685, #686, #687, and #690, then review the stated merge order and the conflict in util.rs. This is a release-triage tracker rather than a self-contained contribution; it is done when the selected fixes, documentation, pin bump, and release-note decision are coordinated.

Tracking issue for the sync work opened over the last two days, with a recommendation on what should and should not land in the imminent v0.14.0 desktop release.

Context: v0.14.0b6 is cut as a draft; aw-android v0.14.1 is already Play Store Latest. The desktop bundle ships aw-sync via the aw-server-rust submodule, so whatever is merged there before the final pin bump ships in v0.14.0.

Everything found

Recommended for v0.14.0

All bug fixes against already-shipped behaviour, none of them migrations:

• ActivityWatch/aw-server-rust#685 (via ActivityWatch/aw-server-rust#682) — without it desktop sync is push-only into a directory nothing reads. This is the release-blocking one.
• ActivityWatch/aw-server-rust#686 (via ActivityWatch/aw-server-rust#683) — defensive, and the urgency comes from Android: the hostname sanitization is in aw-android v0.14.0 and v0.14.1, i.e. already on the Play Store, so users are forking their sync folders now while desktop has no defence. Mitigating factor: Android sync is off by default (isSyncEnabled() defaults false) and needs an explicit SAF directory pick, so the blast radius is users who deliberately turned sync on — which is exactly the population that would hit ActivityWatch/aw-server-rust#683 hardest.
• ActivityWatch/aw-server-rust#688 — small, and ActivityWatch/aw-server-rust#685 is what makes it matter: today the daemon barely does anything on the pull side, afterwards it walks every peer database each cycle, so "one error kills the daemon forever" becomes load-bearing.
• ActivityWatch/aw-server-rust#690 — docs only; the README currently tells people to run the broken command.

Merge order matters: ActivityWatch/aw-server-rust#686 → ActivityWatch/aw-server-rust#687 → ActivityWatch/aw-server-rust#685 rebased. ActivityWatch/aw-server-rust#685 conflicts with both others in util.rs; ActivityWatch/aw-server-rust#686 and ActivityWatch/aw-server-rust#687 compose cleanly. See the review comments on each PR.

Land if ready, otherwise defer

• ActivityWatch/aw-server-rust#687 — additive: a new read-only subcommand plus extra warnings, no existing path changes shape. High support value for exactly the users who will hit sync trouble in this release. Not worth holding the release for.

Defer past v0.14.0

Everything here either rewrites data or moves files inside a Syncthing mesh. That is not rollback-safe — downgrading the app does not un-replicate a rename to every peer — so it wants a beta cycle, not a final release:

• aw-android#272 — ships on Android's own cadence anyway; involves migrating bucket hostnames.
• ActivityWatch/aw-server-rust#689 items 1–2 — deleting the orphaned staging db propagates the delete to every device. Correct outcome, but it should be a deliberate user action with status showing what will happen first, which argues for doing it after ActivityWatch/aw-server-rust#687 has shipped and been used.
• #302 / aw-server-rust#649 stages 2–3 — making device_id authoritative for provenance. Worth doing, definitely not two days before a release.
• ActivityWatch/aw-server-rust#684 items 3–6 — manifest.json, Raw Data peer surfacing, walker unification, test.db rename.
• aw-webui#982 — only becomes visible once data.device_id is populated, which is deferred anyway. Cheap to fix whenever.

Release-note item

After ActivityWatch/aw-server-rust#685, the first daemon cycle on an existing install performs a full backfill from every peer that has ever written to the sync folder. On my own mesh that is ~1M events / 273 MB from a single Android peer, plus several desktops. Expect sustained CPU and disk on first run after upgrading, and a large database growth. Worth a line in the release notes so it does not read as a regression — and a decent argument for shipping ActivityWatch/aw-server-rust#687 alongside, so users can run aw-sync status and see what is about to be imported.

cc @TimeToBuildBob — ActivityWatch/aw-server-rust#688, ActivityWatch/aw-server-rust#689, ActivityWatch/aw-server-rust#690 and aw-webui#982 are unclaimed; ActivityWatch/aw-server-rust#690 is the smallest and aw-android#272 is the one nothing currently addresses.