e2e: every failing test prints its daemons' logs

[ChakraFusion]

A timing failure in CI arrives as one line ("offers = []", "daemon never became ready") with nothing to say what the daemons did, and it rarely happens twice: the cloud-offer failure behind #56 took 150 runs on Windows runners to see again. Until now only 12 tests printed their daemons' logs (logOnFailure), each by asking for it.

• testutil.NewTestDaemon prints the daemon's log whenever its test fails, after the daemon has stopped, so its shutdown is in it too. logOnFailure and its calls are removed, since every test now has it.
• The CLI harness prints the daemon process's opensave.log before the test's home folder is removed. A daemon that never became ready now also says whether it published its address and what the last daemon status answered (the failure seen on sync: a peer that pulled says what it now holds, so the base is recorded at once #51).

Tests only; no product code changes. Checked with a deliberately failing test of each kind.

🤖 Generated with Claude Code

[vercel]

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

A member of the Team first needs to authorize it.

[ChakraFusion]

The failing job is TestMultiRootScenario_ALateReportDoesNotHideADivergence on Windows, the extra-location flake from #21's original post. This PR only changes how tests print logs, so it's unrelated, and a re-run should pass. But it did its job: the failure printed both daemons' logs, and they show what happened.

1. B's watcher didn't stop when the test switched auto-sync off ("did not stop within 5s and was abandoned"). Its snapshot was still running, and when that finished it started a sync anyway. That sync told A "in sync", so A recorded a fresh last-synced time just before the test's edits.
2. A location with no merge base is judged by file times against that last-synced time plus a 2-second clock-skew tolerance (DetectConflict's fallback). Edits within 2 s of it count as unchanged on both sides, so no conflict was raised and A took B's version. I reproduced this deterministically: a genuine agreement, the base cleared as the test does, both edits straight away, and no conflict, 3/3.

The fix for 1 (the trigger) is #58: a watch stopped during its snapshot keeps the snapshot but starts nothing, and a change reported for a game with auto-sync off doesn't start a sync.

2 is a question for you rather than a fix I'd just send: in the fallback, a side whose newest file is within the tolerance of the last sync could count as changed. That raises a conflict when it can't tell, instead of picking a side, at the risk of a prompt right after a sync. Save versions for locations would replace that fallback altogether. Would you like either?

[Omar-VF]

Thanks, the logs did exactly their job. On the 2-second fallback: yes, please send option 1, but narrowly. Count an edit within the tolerance as a change, and raise a conflict only when both sides have one. When just one side does, it can still win as it does now. An occasional extra prompt right after a sync is a better failure than a silently lost edit, and since save versions are postponed, we'd rather not leave this waiting on them. Against dev-public as before.

[ChakraFusion]

Sent as #72. Any edit after the last sync now counts as a change. A conflict still needs both sides changed, and one side alone wins as before. There's a unit table and an e2e test that fails 3/3 without it.

I first moved the 2 s before the sync instead of dropping it, but that turned a just-pulled copy into a "change" and broke two sync tests, so #72 drops it. The description has the details.