Support getSync for rave-level followers, refactor connection flow

[germanoeich]

Summary

Refactors the connection flows.
Adds getSync() support to rave-level on top of the new many-level opt-in hook.

Changes:

• refactors the leader connection flow to make the connect / become-leader path easier to follow
• enables getSync in the rave-level guest options
• adds a same-process leader registry so local follower instances can avoid deadlocking
• adds a dedicated get-sync.js helper for the blocking follower implementation
• implements follower getSync() by doing the async socket read in a worker thread, while the caller blocks with Atomics.wait()
• adds coverage for:
  • leader getSync
  • same-process follower getSync
  • cross-process follower getSync
  • missing keys
  • JSON value decoding

Notes

This PR depends on the many-level PR that adds opt-in getSync support. Before merge, the many-level dependency hash should be updated to the merged many-level commit.

Follower getSync({ snapshot }) is explicitly rejected with LEVEL_NOT_SUPPORTED. Supporting that correctly would require a broader distributed snapshot identity / lifetime model, which is intentionally out of scope here.

Related PR: ForgeVTT/many-level#3

[oneirocosm]

This is admittedly a bit tricky to make consistent, but would it be possible to add a test that ensure getSync blocks the event loop? Almost all of the ideas that I can think of rely on timestamps which I don't think are very reliable, but if you know of another way, that could be useful.

[germanoeich]

@oneirocosm Its tricky, since this has a leader and follower model we could spawn two processes, bootstrap rave-level and a leader and run a background worker as follower, but inspecting the worker and the setup for this will be really clunky, I'd rather avoid it to be honest