fix(watcher): never track phantom event paths; fail over when the tracked file vanishes

[phraktle]

Problem

The file watcher can wedge permanently: OBS keeps reporting ready with live connections but serves nothing, while the log fills with

ERROR server::listeners::order_book::parallel] Failed to open <data>/node_order_statuses_streaming/20260712: No such file or directory

at ~300 lines/sec — a flat date path that never exists (the node writes hourly/<date>/<hour>). We've now hit this in production on 2026-07-04, 07-09, 07-11 and 07-12, and each occurrence coincides to the second with an hl-visor child restart (the visor restarts hl-node on its own at 95% system memory, so any node with growing memory triggers this regularly).

Root cause

During the restart's directory churn, the recursive notify watcher emits a create event attributed to the wrong parent: the day-directory create arrives as <root>/YYYYMMDD instead of <root>/hourly/YYYYMMDD. The event loop's only guard is if path.is_dir() { continue; } — which is false for a nonexistent path — so the phantom passes as a file and becomes current_path. From there it's unrecoverable:

• on_modify() fails to re-open the path on every ~1 ms poll (hence the log flood), and
• check_for_newer_file() only switches when current_path.metadata() succeeds, which it never does again.

Fix (two commits)

1. Fail over when the tracked file vanishes — check_for_newer_file() treats a dead current_path (metadata error) as "switch to the newest existing file". Recovery net for any way the tracked path can disappear (this also covers external deletion/pruning).
2. Never track a phantom in the first place — require the event path to be an existing regular file (is_file()) before tracking, and log the open failure once per tracked path instead of at poll rate (~290k identical lines in one 15-minute incident window).

Testing

• cargo test -p server: 231 passed, 0 failed on this branch.
• New regression tests: tracked-file-vanishes failover (ghost path → fails over to the live hourly file) and newest-file-stays-current.
• Root-cause evidence from production journals available if useful (timestamps of visor child restarts vs. first phantom-open error match to the second on all four incidents).