Enhance vehicle color synchronization and rendering consistency

[QueryOfficial]

Summary

Fix vehicle colors 3 and 4 randomly disappearing after a vehicle streams out and back in.

MTA applies custom RGB vehicle colors by hooking GTA's CVehicleModelInfo::SetEditableMaterialsCB. The hook writes vehColors[esi] onto editable materials, but esi was a GTA palette index, not the color slot (0–3). That mismatch caused tertiary/quaternary materials to read the wrong entry from the shared vehColors buffer—most notably quaternary (ms_currentCol[3] == 0) always using vehColors[0] (primary).

This PR:

1. CMultiplayerSA.cpp – Patches the four movzx esi, ms_currentCol[n] sites in SetEditableMaterialsCB so esi holds the slot index (0–3) before HOOK_VehColCB runs. Clears the global vehColors buffer when SaveVehColors cannot resolve an MTA vehicle, so stale colors from a previously rendered vehicle are not reused.
2. CVehicleSA.cpp – Updates SetColor to sync m_colour1–m_colour4 on the GTA vehicle interface from the RGB values, so engine paths that read palette indices (e.g. CVehicle::SetupRender) stay consistent after stream-in recreation.
3. CClientVehicle.cpp – Applies saved MTA colors immediately after AddVehicle / SetStoredPointer during Create(), before other setup that may trigger rendering, so the first post-stream-in SetupRender does not use GTA's default palette colors.

Colors 1 and 2 often appeared correct because secondary is hardcoded to palette index 1 in the existing hook path, which accidentally matched slot 1. Tertiary/quaternary had no such luck and failed intermittently depending on palette values and render order.

Motivation

Fixes #4982.

Reported behaviour: after setVehicleColor with all four RGB colors, colors 1 and 2 remain correct while colors 3 and/or 4 can reset or vanish when the vehicle streams out and back in. The issue is intermittent because it depends on palette indices, shared global state, and timing around stream-in.

Root cause: HOOK_VehColCB treats esi as a vehColors array index, but GTA stores a palette table index in esi at that point. Quaternary materials always ended up with index 0, so they showed the primary color or black instead of the intended RGB value.

Test plan

1. Build the client from this branch.
2. Spawn a vehicle that supports 4 editable color slots (e.g. models with tertiary/quaternary materials).
3. Apply four distinct RGB colors via setVehicleColor:

   setVehicleColor(vehicle, 255, 0, 0, 0, 255, 0, 0, 0, 255, 255, 255, 0)

4. Move far enough away for the vehicle to stream out, then return so it streams back in.
5. Repeat steps 4–5 several times.
6. Confirm colors 3 and 4 remain applied; colors 1 and 2 should still be correct.
7. Optional regression checks:
   • Palette-format setVehicleColor(veh, p1, p2, p3, p4)
   • Vehicles with paintjobs / remaps
   • Multiple vehicles with different 4-color setups visible at once (no cross-vehicle color bleed)

Checklist

• Your code should follow the coding guidelines.
• Smaller pull requests are easier to review. If your pull request is beefy, your pull request should be reviewable commit-by-commit.

[Dryxio]

1. The Create() hunk seems redundant. There's already an unconditional SetColor further down in the same function ("Restore the color"), and Create() is synchronous, so no SetupRender can run between the two calls. The scenario described in the comment can't actually happen. I'd just drop this hunk.

2. I don't think the root cause is what the description says. HOOK_VehCol already forces the colour args to 0/1/2/3 on the SetupRender path, so ms_currentCol is already {0,1,2,3} there and the movzx patch does nothing on that path. My guess is the fix works because it removes the out-of-bounds vehColors read on paths that bypass HOOK_VehCol.

Besides that looks good!

[QueryOfficial]

Good points, thanks — dropped the redundant early Create() SetColor hunk and rewrote the root-cause comment to reflect that the movzx patch matters on non-SetupRender paths, not the SetupRender path where HOOK_VehCol already sets slot indices. Also removed the unnecessary m_colour1–4 sync in CVehicleSA::SetColor.