End-to-end multi-instance test harness

Blocked by #56 (Manual peer addition) — needed for deterministic, multicast-free discovery between the two spawned instances. Deferred until that lands.

Goal

Every test today is in-process and uses the in-memory adapters via crate::utils::test_support::test_env(). That's great for unit coverage but never exercises the real concurrent stack: two synchronizers talking over real TCP, real mDNS (or manual peer), and real filesystem watching.

Add an integration suite that spawns two real synche binaries and asserts an actual end-to-end sync.

Depends on: Issue ''Configurable ports and basic CLI flags'' (so the two instances can be told to use different ports and config dirs) and likely the ''Manual peer addition'' issue (so discovery is deterministic in CI without relying on multicast).

Requirements

• New app/tests/e2e/ integration test crate (or #[test]s under tests/).
• A small helper that builds the binary once and, per test, spawns two child processes with:
  • Separate temp SyncheDirs (and so separate config.toml, data.db, device_id)
  • Different ports (via the CLI flags from the configurable-ports issue)
  • Each pointed at the other as a manual peer
• Golden-path test: write hello.txt into side A's sync dir → assert it appears on side B within a timeout, byte-identical.
• Deletion test: delete on A → tombstone propagates to B.
• Conflict test: edit the same file on both sides while disconnected, reconnect, assert a conflict file is materialized on both sides (per VersionCmp::Conflict).
• Tests must clean up child processes on failure (drop guards / kill on panic).
• Reasonable timeouts so CI doesn't hang forever on a regression.

Out of scope

• Performance benchmarking (separate concern)
• Multi-peer (>2) scenarios (start with two; expand later)

Acceptance criteria

• cargo test -p synche --test e2e (or equivalent) runs the suite and passes locally
• Killing one of the spawned children mid-test does not leave orphan processes
• At least the three scenarios above (add, delete, conflict) are covered
• CI runs the suite (or there's a follow-up issue to wire it in)