Modernize Vehicle Framework compatibility

[sviyh]

Summary

• modernize the Vehicle Framework patch to use named Multiplayer and Vehicle Framework APIs wherever available
• synchronize caravan seats, routes, send, passenger transfer, cargo orders, turrets, fuel, and flight actions at their real UI or session boundaries
• keep Vehicle Framework path and region state deterministic by disabling/releasing its map worker and executing the remaining VF task-dispatch boundaries synchronously in multiplayer
• remove copied mod logic, obsolete wrappers, dead code, unnecessary reflection, and redundant serializers while retaining narrowly justified access to MP internals and generated callbacks

Root cause

The patch had accumulated low-level interception and reconstruction paths that duplicated Vehicle Framework or Multiplayer behavior or serialized transient UI state. The caravan integration also crossed the Multiplayer session boundary incompletely: tab initialization could skip VF's tab setup, seat commits omitted the vehicle transferable, route selection bypassed the MP session, and the final send path could bypass Vehicle Framework's vehicle-caravan action.

Vehicle Framework also maintains process-local asynchronous path/region work and a shuffled static edge-cell cache. Those can differ between peers and affect reachability and caravan exit selection.

Closes rwmt#561.

Approach

• use direct MP.RegisterSyncMethod registrations for named VF actions
• rely on Multiplayer's native serialization where the target is supported; retain one stable vehicle-plus-pawn-ID argument transform for held pawns whose holder is a VehicleRoleHandler
• use VF's stable keyed component/turret/handler accessors
• let VF perform its own validation and state transitions; redirect only the final synchronized action boundary
• commit seat changes atomically to the active ISessionWithTransferables, including pawn counts, vehicle count, assignments, and notifications
• route VF's custom chooser through MP's existing caravan-forming session while preserving VF's exit-tile result at the exact calculation site
• execute VF's actual final vehicle-caravan and forced-departure functions through synchronized targets
• initialize VF caravan tabs without allowing vanilla to replace the proxy's shared transferables
• restore VF's missing idle-job target after serialization when necessary
• mirror MP's route-planner lifetime behavior for VehicleRoutePlanner.ShouldStop
• disable and release VF's map pathing worker, and replace only VF's remaining TaskManager.Run(Action, CancellationToken) pathing call sites while in multiplayer
• reset VF's private shuffled edge-cell cache before multiplayer use; VF currently exposes no cache invalidation API
• keep reflection only for internal MP client-session types, compiler-generated callbacks/local functions, Harmony target discovery, and optional declared add-on overrides

Test plan and results

• rebased onto current upstream master (bcffd466)
• main and referenced Release projects build with 0 warnings and 0 errors
• rebuilt/deployed referenced DLL SHA-256: 7435D804880E12F45AAC0BEFD48E4203564B22735FCB457A3133AAB3EE7108A7
• host and client connect with identical state and desynced=false
• synchronized god mode and Architect placement create identical Dinghy and Roadkill fixtures on both peers
• MP caravan proxy renders VF's Vehicles tab without recaching the shared transferables
• real Assign Seats dialog commits Rammi plus the selected vehicle atomically on both peers
• real Change route opens VF's planner and commits identical MP session destination/starting tiles on both peers
• real Roadkill Send plus warning confirmation runs VF validation, assigns the driver, boards the pawn, exits the map, and creates an identical moving VehicleCaravan on both peers
• after another 301 synchronized ticks, both peers still agree on caravan state and remain ClientPlaying, desynced=false, with no new desync archive
• Dinghy route/seat/menu synchronization completes without desync
• current final source state was deployed for manual testing and accepted by the maintainer before upstream promotion
• Dinghy map exit was not validated on the generated QA map: VF's own TryFindExitSpot rejected every tested exit even though the connected water component reached the south edge; the rejection was synchronized and separate from the custom UI/session synchronization
• the generic UI driver could not distinguish the second of two visually identical horizontal vehicle cards; the second seat transaction was exercised through the existing method-boundary QA probe
• broader cargo, turret, upgrade, damage, aerial-flight, landing, stash, and passenger regression remains optional follow-up coverage

Related open work

This substantially overlaps the older caravan implementation in rwmt#592. PR rwmt#620 also edits VehicleFramework.cs and contains additional RimThunder/VF fixes; those are not presented as part of this PR and will need conflict resolution whichever change lands first.

QA notes

The final automated caravan run completed 6/6 synchronization checkpoints through real host/client UI and MP command paths. A QA-only in-memory postfix tracer confirmed the Roadkill send reached VF's real validation, exit selection, packing, and formation methods successfully on both peers; no production logging or state repair was added.

An attempted manual path-grid normalization was removed before the successful run after it produced an IndexOutOfRangeException inside VF's region connector. The submitted patch relies on VF's lifecycle and changes only asynchronous scheduling boundaries.

The known RimBridge reflection-only UnityEngine.InputLegacyModule diagnostic is a QA-harness issue; it is not suppressed or handled by this production patch.