Allow com_maxfps values up to 1000 in the console

[akacross]

Summary

• keep com_maxfps validation and completion aligned at 0..1000
• expand interactive console completion storage from 64 to 1024 candidates so values above 63 are not discarded
• keep 0 as the uncapped value

Validation

• client target builds successfully
• console translation unit compiles successfully
• staged runtime packages updated

[themuffinator]

Thanks! This fixes the com_maxfps case. With the completion popup on (the default), the console collected only the first 64 values of ArgCompletion_Integer<0,1000>. Typing a cap like 144 left the popup open with no exact match. Enter then applied the highlighted entry instead of running the command, which replaced the value you typed. At 1024 the whole 0–1000 range is in the list, so an exact value closes the popup and Enter runs the command.

Two notes for the record:

• The fuzzy-completion buffer in RefreshCompletionState grows with the cap, to about 272 KB on the main thread's stack. That fits easily in its 16 MB (Windows) or 8 MB (Linux/macOS) stack.
• The underlying cause is that argument candidates aren't narrowed by what you've typed. Cvars with wider ranges, such as com_loadingContinueAutoAdvance (0–60000), still behave this way; that needs a separate fix in the completion filtering.

CI is green across the matrix. Squash-merging, since the branch's intermediate commits change and then restore the com_maxfps bound.