Rate limit and bound chat from remote clients

[Tyrathalis]

Summary

Chat from a remote client is accepted before login and rebroadcast to every peer, and nothing bounds how fast those messages arrive. A client sending chat in a loop costs the host's CPU, everyone's bandwidth and everyone's scrollback at once.

This adds a per-client token bucket, and makes the existing length bound on the rebroadcast configurable.

Behaviour

• Token bucket sized for a person typing: 10 message burst, one refilled per second. Over-rate messages are dropped rather than queued, since queuing is what the sender wants.
• The rebroadcast length cap becomes a property instead of LogSafe's default.

Both are policy rather than correctness, so both are tunable and both can be switched off outright:

property	default	off
forge.net.chatBurst	10	0
forge.net.chatRefillMillis	1000	—
forge.net.maxChatLength	512	0

These sit alongside the existing forge.net.heartbeatTimeout. The defaults are a guess at "generous for a human" — if they are wrong for how people actually use the lobby, they are one property away rather than a rebuild.

Switching the cap off still strips control characters from the rebroadcast: that part is a correctness property, not an anti-spam measure, so only the truncation is optional.

Values are read per call rather than into static final fields, because Integer.getInteger in a static initialiser is fixed at class-load and surefire shares one JVM, so a test could not otherwise vary them.

Deliberately not included

A general per-message rate limit covering all inbound traffic. That risks throttling legitimate high-rate game traffic, and there is no measured baseline here for what a busy turn sends — guessing a number and stalling a real game is how this kind of change gets reverted.

Tests

ChatRateLimitTest, 2 unit tests, no server and no socket: the bucket empties and refills, and the disable switch never refuses.

---

Portions authored with an AI assistant (Claude), reviewed by a human.

[MostCromulent]

No problem in principle, but what was the situation that led to the need for this?

[Tyrathalis]

No inciting incident. I was looking at ways clients could overload each other (for 2df8aaa) and noticed there were no spam protections. Spam isn't much of an issue with no public rooms or matchmaking, but it seemed like an easy fix, so here it is if you're interested. The limits are off-switchable if the defaults turn out wrong for how people actually use the lobby.

[MostCromulent]

@tool4ever I don't have a hard view against this, but it does seem to be solving a problem that doesn't actually exist in practice.

[tool4ever]

ok thanks, yea this could become more interesting if lobbies were more broadly available like on some forks
though I'm not sure they're even using this chat system in that case 🤔
will consider it a bit more when my backlog is a bit less full