perf: stop rebuilding the center html panel event on every tick

[makadore]

CenterHtmlMenuInstance.Display is registered as an OnTick listener, and the panel only stays on screen while it is being resent, so an open menu goes through this path 64 times a second for every player looking at it.

PrintToCenterHtml creates a game event, fires it and frees it. Doing that on every tick is most of what an open menu costs. The event is kept for as long as the menu is and refilled with the new markup instead, then freed in Close.

Measurement

Taken on a live CS2 server with a 12 item menu, by alternating the two send paths on every other render so both meet the same conditions rather than running one after the other:

path	sends	per send
create and free each tick	2466	36.57us
keep and refill	2466	27.54us

The same change in CounterStrikeSharp's own CenterHtmlMenu measured 36.81us against 29.02us, which is where the confidence in this number comes from — two separate code bases, same mechanism, same size of gain.

The smaller half

AddPageOptions asks the localizer for Prev, Exit and Next on every render, unconditionally, even when those buttons are not shown. Each of those calls goes through ReplaceColorTags, which reflects over ChatColors. Benchmarked on its own that is 0.324us a call, so about 1us of the 37 — real but not the main cost. The labels are read once when the menu is opened instead, and one StringBuilder is reused rather than allocated per render.

Colours are still read on every render, since a plugin can change CenterHtmlMenu_PrevPageColor and friends after the menu is built.

One behaviour note

Sending returns early when the player is no longer valid rather than throwing, which is what PrintToCenterHtml does through an internal guard that is not reachable from here. For something that runs every tick that seemed the better of the two, and Close already checks Player.IsValid the same way.

Checked in game: menu opens, pages turn, items select, closes on select and on !0.