Changelog

1.1.3

Admin check: on servers where the ACE check answers 1 / 0 instead of true / false, every player was treated as an admin (0 counts as yes in Lua) and could open the handling editor and manage profiles. The ACE permission (Config.Permissions.ace) and the group.* checks now accept only true or 1.

Offline test for the 1 / 0 ACE answer.
ARCHITECTURE.md: profiles, applying handling (state bag + GlobalState), request contract, data ownership.
Offline tests (lua5.4 tests/run_tests.lua): field validation, sanitising, router gates, editor and profile lifecycle (version conflict, history / restore, activate, delete rules), public actions. Not shipped.

/vhcompare debug command (admin, Config.Debug): compares the handling and effective values of two vehicles of the same model.

Activating a profile now always applies it to every spawned vehicle of that model (including the vehicle being edited). The "also apply to vehicles that are already spawned" checkbox and Config.AutoApply.applyExistingOnActivate were removed (the option can be deleted from config.lua).

Newly spawned vehicles often did not fully use the active profile (e.g. a 1-gear profile spawned with 6 gears; other spawn-cached values differed from Apply & refresh): it was written after the vehicle had been created and its mods applied. The active profile is now written into the model's global handling on every client (GlobalState), so vehicles are created with it. New Config.HandlingNames for add-ons whose handlingId differs from the model name.
Vehicles spawned without a mod kit (e.g. /car) drove differently from the same vehicle after Apply & refresh. The mod kit is now set before the profile is applied, like Apply & refresh does.
After activating a profile and closing the editor, the vehicle sometimes reverted to Default or to the previously applied profile instead of the new active one.
The editor previewed the active profile on vehicles that were explicitly stock; it now shows Default as the applied profile for them.
The driver fallback (claim) was skipped for vehicles that reused the network id of an earlier vehicle, and was never retried after a timeout / rate limit, so such vehicles could spawn with Default handling.
Profile / default value fetches could be rate limited when several vehicles streamed in at once, leaving those vehicles unsynced.

Active profile was not applied to newly spawned vehicles with some spawn methods (server-created vehicles / entities whose type was not replicated yet when entityCreated fired). The server now retries briefly, and the driver's client asks once for the active profile as a fallback.
Profile is applied a second time shortly after spawn, so garages that set vehicle properties right after spawning cannot undo it.

Activating a profile without "apply to existing vehicles" now marks already spawned, untouched vehicles of that model as stock, so only new spawns get the profile.

Help page in the editor: short tuning tips (acceleration, top speed, grip, brakes, drift, durability). Each tip links to the fields it mentions.

Activating a profile failed with "Database error" on oxmysql (TINYINT(1) values are returned as booleans).