Add player max sync speed parameter and enhance puresync validation

[QueryOfficial]

Summary

Adds server-side on-foot puresync sync-manipulation guard — forged position/velocity is dropped before server state updates or relay to other clients.

• New mtaserver.conf setting: <player_max_sync_speed> (default 360 km/h, 0 disables)
• CPlayer / CSimPlayer track last accepted puresync baseline (position, tick, vehicle contact-relative coords)
• Validation in CPlayerPuresyncPacket + CSimPlayerPuresyncPacket (main + sim thread, before apply/relay)
• Rejects impossible velocity, position delta (1.35× margin), and NaN/Inf coordinates
• Vehicle surf uses contact-relative delta to avoid false positives on fast vehicles
• Docs: Server/mods/deathmatch/README.sync-manipulation-guard.md

No client or netcode protocol changes.

---

Motivation

Sync-manipulation cheats forge outgoing on-foot puresync while staying on foot locally. The server used to accept and relay that sync; remote clients then simulated impossible movement and launched nearby vehicles/players.

This fix rejects forged packets at the server read stage on both main and sim threads. Threshold-based (max believable on-foot speed), not full GTA physics — balances protection vs. jetpack, knockback, ping, and vehicle surf.

---

Test plan

Build this branch, use 2 clients (attacker on foot + victim in a nearby vehicle), private test server, default <player_max_sync_speed>360</player_max_sync_speed>.

Repro script — mirrors the documented exploit; requires a client that can forge outgoing puresync (api.sync.* = cheat/test hook):

-- test-sync-forge/client.lua (private test server only)
local MAX_DIST, FORGE_SPEED = 30.0, 100.0

local function nearestVehiclePlayer()
    local px, py = getElementPosition(localPlayer)
    local best, tx, ty, tz = MAX_DIST
    for _, p in ipairs(getElementsByType("player")) do
        if p ~= localPlayer and isElement(getPedOccupiedVehicle(p)) then
            local x, y, z = getElementPosition(p)
            local d = getDistanceBetweenPoints2D(px, py, x, y)
            if d < best then best, tx, ty, tz = d, x, y, z end
        end
    end
    return tx, ty, tz
end

local function forgeVelocityToward(tx, ty, tz, zOff)
    local px, py, pz = getElementPosition(localPlayer)
    local dx, dy, dz = tx - px, ty - py, (tz + zOff) - pz
    local len = math.sqrt(dx*dx + dy*dy + dz*dz)
    if len < 0.01 then return end
    api.sync.velocity(dx/len*FORGE_SPEED, dy/len*FORGE_SPEED, dz/len*FORGE_SPEED)
end

addEventHandler("onClientPreRender", root, function()
    local tx, ty, tz = nearestVehiclePlayer()
    if not tx then return end
    if getKeyState("v") then forgeVelocityToward(tx, ty, tz, 1) end
    if getKeyState("p") then
        api.sync.position(tx, ty, tz - 0.7)
        forgeVelocityToward(tx, ty, tz, 2)
    end
end)

Expected results

• Hold V or P near victim → victim's vehicle not launched; attacker not teleporting on victim's screen
• Repeat with clients in sim relay range → same (sim thread must not relay first)
• Set <player_max_sync_speed>0</player_max_sync_speed> → exploit works again (confirms wiring)
• Normal walk/sprint/jump, vehicle surf, enter/exit vehicle, server teleport (setElementPosition) → no false positives at default 360

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.