The v1.0.11 client log ends on a stock menu callback failure. It is not a mod
download failure or an allocation failure. That run had no required mod
payloads and completed its initial checkpoint verification before stopping.

New menu integrations emit events 18..23 and 100..105. The no-owner branch in
the owned runtime only recognised the earlier notifications through event 17.
The real native handler returns harmlessly when the corresponding menu owner
is absent. The revised guard now matches that known notification surface.
The dispatch fixtures extract the actual compiled function for both supported
ROM revisions. The old function fails the test; the staged function passes.
Unknown calls remain blocked and an admitted owner still receives calls first.

The later host timeout in that log happens after the runtime returns to the
launcher. It is not evidence that the first fault was a failed connection.
Likewise, the legacy network counters reporting zero samples do not measure
the party runtime. New party counters report progress and rollback work there.

The launch-to-first-picture gap in that stock run was about 13.3 seconds.
The compressed initial checkpoint was about 1.39 MiB. Previously its SDK lane
could hold 16 KiB and the runtime supplied one chunk per peer on each pulse.
Setup now has a bounded 256 KiB allowance and can supply four chunks per peer.
The existing small queues and pacing remain in use for spectators during a race.

Mod payloads used the same small SDK bulk lane. They now receive the larger
allowance only at the authenticated ModData send boundary. The application
window remains 256 KiB, with the existing active-slot fairness and backpressure.
This SDK queue bound is not an estimate of bytes in flight or an RTT window.
The resulting throughput still depends on the host's upload and each route.

Partial downloads previously forced a durable disk flush every 64 KiB. That
can mean roughly 1,800 flushes for 111.9 MiB, depending on file boundaries.
The batch is now 1 MiB, with an unconditional final flush before publication.
SHA-256, exact size, atomic publication and the five gap repairs remain intact.

Earlier playtest logs, not the supplied v1.0.11 session, showed the whole
111.9 MiB selection already cached. Their wait was local preparation: about
15.4 seconds in one run and 39.2 seconds in another. Download byte totals alone
cannot tell you how much time was spent transferring files. The revised log
separates setup/payload phases and records resource preparation phases.

Those earlier prepared resources totalled about 545 MiB, which exceeded the
old 512 MiB optional retention ceiling. A capable desktop can now retain one
collection up to 768 MiB, still limited to physical RAM / 16 and available
RAM / 4. Pressure is checked again before reuse. Small-memory systems retain
their lower limits, and unrelated cached collections are released first.

Racing inputs shared the ordered lobby control channel. They now use the
existing reliable unordered authority channel, with the same authenticated
ownership, immutable history, conflict checks and bounded repairs. This removes
that ordering dependency; it does not change game clocks or promise that every
source of stutter has been eliminated. The new timings distinguish CPU tick
cost, rollback work and missing confirmed progress in subsequent tests.

The Windows updater child launcher inherited the CRT runtime log handle.
That could prevent the successor rotating the log, losing the very gameplay
evidence needed after an update. Child creation now excludes inherited handles,
and persistent log handles are marked non-inheritable too. A busy current log
uses a separate file in the existing bounded history folder.

Automated checks use synthetic CPU worlds, temporary files and mod archives as
data. Real racing, spectator output and route performance require the matching
Windows and Linux test builds on the players' machines.
