fix(sync): prefer agreed base over misleading file mtimes

[Seagulls]

Refs #41.

When both peers have a confirmed common manifest, and exactly one side later changes, that change should win. A touched, copied, or restored copy of the old save can have a newer file mtime and is not an edit.

This is a source-level correction. It is not a reconstruction of any particular historical incident.

What changes

ComputeWithDeletions used to rank differing files by MtimeMs before asking whether one whole manifest was still the agreed hash. The newer timestamp could then overwrite the only real edit, with no conflict.

If one side's whole manifest still equals the confirmed base and the other does not, the changed side wins, in either direction. Named extra locations now pass the same agreed hash into that decision. They previously computed direction with an empty base.

agreed base:  slot.sav = A
local:        slot.sav = A, mtime later   (touched copy)
remote:       slot.sav = B, mtime earlier (the only edit)

before: push A over B
after:  pull B

A recorded deletion is not undone by a later mtime on the surviving copy. Identical contents do not transfer. If both sides differ from the base, the existing conflict path is unchanged.

What this does not do

A missing or stale agreed hash still uses the old mtime fallback. That can still be wrong. This PR does not add version vectors, and it does not replace the design in #29 / draft #30.

#30 decides sync from save versions and touches a much wider set of files, including internal/p2p/syncengine/version.go and migrations 0038/0039. This branch only changes the existing agreed-hash comparison in decision.go and multiroot.go. The two can be reviewed separately. If both land, the maintainer should choose which decision model remains.

Tests

Red on unmodified 346d9bda: TestBaseFirstPreventsMtimeRollback followed the newer mtime (incorrect push and pull). Green on this branch.

Also covered: both directions on real isolated daemons for the primary folder and a named extra root; symmetric deletion; equal contents; no base; stale base; both sides changed.

Check	Result
go test -count=1 -timeout 25m ./e2e/... on aee1c1a	pass, about 764s, Go 1.27.1
go test -race for the agreed-base filters	pass, Go 1.27.1
-count=3 on the rollback and daemon-direction tests	pass, Go 1.27.1
go vet, gofmt, git diff --check	pass
Focused unit rerun on Go 1.26.4 at aee1c1a	pass

Toolchain: Linux only. The full earlier suite used go1.27.1-X:nodwarf5. go.mod requests Go 1.26.4. This tip was not rebuilt as a full E2E run on 1.26.4 because the commit is unchanged from that green run. No Windows or macOS run.

TestSessionNamesTheSnapshotAlreadyTaken fails on an untouched archive of 346d9bda (extra Auto backup snapshot; want the watcher). This branch does not change session code. The timestamp package gate did not include ./internal/daemon for that reason. go test ./... also cannot build cmd/opensave-app here: it embeds frontend/dist, which is not in the clone. Neither was stubbed.

[vercel]

Someone is attempting to deploy a commit to the sivadaboi's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Omar-VF]

Thanks, and for #41. We reproduced the rollback on 2.4.1 with your test, and CI is green against dev-public (where this PR now targets). When you're happy with it, please mark it ready for review and we'll merge it.

[Omar-VF]

Merged into dev-public. Thanks for the clear reproduction.