Fix chat priority starvation under high load

[Zephkek]

Summary

Raise chat echo and clear packets from low to medium priority.

Motivation

Resolves #4872. At high player counts, low-priority reliable chat packets can be starved by constant sync traffic, while commands and client events remain responsive because they use higher priority packets.

Test plan

• Verify chat still uses PACKET_ORDERING_CHAT for ordered delivery.

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.

[qaisjp]

Could there be any negative impact to this change, such that other traffic could be starved by chat messages? I'm curious what other "medium priority" messages are now competing with chat.

Just imagining someone trying to flood the server with chat messages as a DOS attack, but I guess that's possible with any packet anyway.

Could you check to see whether there's anything interesting in git blame? I'm guessing it goes back to the initial commit though

[Zephkek]

Could there be any negative impact to this change, such that other traffic could be starved by chat messages? I'm curious what other "medium priority" messages are now competing with chat.

Just imagining someone trying to flood the server with chat messages as a DOS attack, but I guess that's possible with any packet anyway.

Could you check to see whether there's anything interesting in git blame? I'm guessing it goes back to the initial commit though

Chat would mainly be competing with the regular sync packets, like player/vehicle pure sync, key sync, camera sync, ped/object/unoccupied vehicle sync, and bullet sync/custom weapon bullet sync.

So yes, in theory, a sustained chat flood could now put pressure on medium-priority sync traffic rather than only low-priority traffic (though this is irrelevant because if an attacker can manage to send packets through RakNet he can set whatever priority he wants). That said, chat still uses PACKET_ORDERING_CHAT, so it stays on its own ordered channel and should not introduce reliable-ordered blocking on the default sync channel, and ofc high-priority traffic also still stays above it.

I also checked blame. It does not go back to the initial commit:

• CChatEchoPacket was changed from high to low in 97f8fe4eb
  for #6877, specifically "Chat messages don't update while a map download is in progress".
• CChatClearPacket was added later in 600de4948
  and copied the same low-priority behavior/comment.

The remaining tradeoff I see is that chat spam can now contend with normal sync under abuse, but that feels like something better handled with chat/output rate limiting than by keeping chat in a priority class where it can starve during normal high-load sync.