Apex Network

<h1>Apex Network Optimizer - Update v1.7.5 (Handshake Latency)</h1>

<p>Closes the ~8 second gap between login and Apex becoming active. That gap was not cosmetic: until the handshake
    completes neither side has its codec installed, so the single heaviest traffic burst of the entire session — initial
    chunk load and recipe sync — was being sent <strong>uncompressed</strong>.</p>

<h3>⏱️ Why it was 8 seconds</h3>
<p>NeoForge's <code>PayloadRegistrar</code> defaults to <code>HandlerThread.MAIN</code>, which on the client is the
    render thread. During a join that thread is saturated building the world, so the Apex hello sat in its task queue
    behind terrain, entity and mod initialisation work. The delay was never Apex doing anything slow — it was simply
    waiting its turn.</p>

<h3>🔧 The fix</h3>
<ul>
    <li>The hello handshake is now registered with <code>executesOn(HandlerThread.NETWORK)</code>, so it is handled the
        moment it arrives instead of queueing behind world loading.</li>
    <li>Only the handshake was moved. Every other payload (recipes, chunk delta, dictionary sync) still handles on the
        main thread, since those touch game state.</li>
    <li>The handler is safe off the main thread: it touches only the connection's own Apex state and Netty pipeline, and
        its one game-facing action — the chat notification — already hops to the main thread. Handling on the network
        thread additionally puts these writes on the same thread the codec handlers read them from.</li>
</ul>

<h3>🧵 Connection state is now volatile</h3>
<ul>
    <li><code>ApexNetworkState</code> fields are written once by the hello handler and then read from the Netty event
        loop (codec handlers) and the server thread (the packet send mixin). They were plain fields, so a reader could
        observe stale defaults — silently skipping optimizations, or disagreeing with the peer about what had been
        negotiated. They are now volatile. This mattered more once the handshake moved threads, but it was a latent
        hazard before that too.</li>
</ul>

<h3>📉 Expected effect</h3>
<ul>
    <li>Compression, bundling and chunk delta active from the start of the join rather than several seconds in.</li>
    <li>The window in which the two sides run mismatched codecs — the source of the 1.7.1 and 1.7.4 join bugs — shrinks
        from seconds to approximately nothing. The tolerance built for that window (vanilla zlib acceptance, early
        inbound handler installation) is retained, since the window can never be reduced to exactly zero.</li>
</ul>