Fix animations progress & sync

[FileEX]

Summary

• Time synchronization refactor for animations (server-authoritative clock)
• Replaced unreliable GetTimestamp() / GetTickCount64_ usage with a monotonic steady_clock-based tick system.
• Fixed a bug where the server was sending elapsedTime while the client treated it as startTime.
• setPedAnimationProgress now runs in the "same" frame as setPedAnimation (setPedAnimationProgress() does not work when called in the same frame as setPedAnimation() #1172).
• When setPedAnimationProgress is set to 0 on the server, it refreshes the animation startTime.
• On the server side, setPedAnimationProgress updates the animation startTime, ensuring all clients play the animation from the same progress point.

Motivation

Fixes #1172

Test plan

crun ped = createPed(50, getElementPosition(me))
crun setPedAnimation(ped, "ped", "ko_shot_face", -1, false, false, false, true) setPedAnimationProgress(ped, "ko_shot_face", 0.5)

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.

[FileEX]

I'm not sure about the changes to bitstream.h. There could potentially be an issue on Linux. If anyone has an idea how to solve this differently, that would be great.

[Flashmyname]

On 64-bit Linux int64_t and long are the same type, so with the guard the call doesn't fail, it just falls through to Write(long) { Write((int)e); } and truncates to 4 bytes. No warning either, I checked on gcc 15. Windows then reads 8, and speed is right after startTime in both packets.

Maybe something like this instead?

void WriteInt64(std::int64_t v)
{
    Write(static_cast<uint>(static_cast<std::uint64_t>(v) >> 32));
    Write(static_cast<uint>(static_cast<std::uint64_t>(v)));
}

bool ReadInt64(std::int64_t& v)
{
    uint hi, lo;
    if (!Read(hi) || !Read(lo))
        return false;
    v = static_cast<std::int64_t>((static_cast<std::uint64_t>(hi) << 32) | lo);
    return true;
}

Then the guard can go, but the call sites need switching over as well or Linux keeps picking Write(long).

[FileEX]

That's enough. I'll wait for a human review, because this will take forever with Copilot - just going around in circles constantly. Using AI was a mistake after all.