Fix warpPedIntoVehicle desync right after createVehicle

[TheCrazy17]

Summary

Fixes two related problems with warpPedIntoVehicle:

• Warping a player into a vehicle created moments earlier (e.g. inside onResourceStart) used to send the warp to clients before they even knew the vehicle existed. They'd just ignore it, but the server kept thinking the player was inside the vehicle anyway, that permanent mismatch is what caused the "NETWORK TROUBLE" freeze. The warp now waits until clients actually know about the vehicle before being sent, instead of getting silently dropped.
• Separately, the server stops answering a player's on-foot position updates the instant they're marked as being in a vehicle, since it expects vehicle updates instead from then on. That's normally a split-second gap, but it was long enough to occasionally trip the client's "no reply for 10 seconds" watchdog on its own. It now keeps replying during that gap.

Motivation

Fixes #475. Also addresses the same underlying issue reported in #3119 (warping into a train), since both come down to the server and client disagreeing about vehicle occupancy for longer than the client's network-trouble timeout allows; so: Fixes #3119.

Test plan

addEventHandler("onResourceStart", resourceRoot,
    function()
        local vehicle = createVehicle(411, 0, 0, 5)
        warpPedIntoVehicle(getRandomPlayer(), vehicle)
    end
)

• Reproduced the script above locally: before this change, the player would get permanently stuck with "NETWORK TROUBLE" on screen. After, the vehicle warp goes through cleanly.
• Confirmed normal vehicle entry/exit (driving, getting in/out as usual, jacking another player) still works as before, this only changes the resource-start edge case and the puresync acknowledgment timing.

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.