[SBPP Checker] Callback and initial values

[Rushaway]

Ports upstream sbpp#894 (which remains open upstream).

What

As a consumer of the SourceBans checker natives, you currently get stale
g_iBanCounts / g_iCommsCounts values between a client disconnect and the
async OnConnectBanCheck callback, with no signal that the data is valid yet.

This change:

• Initializes the count arrays to -1 so the natives report "not yet
  available" rather than a previous client's numbers.
• Resets the counts to -1 in OnClientDisconnect_Post.
• Adds a global forward SBPP_CheckerClientBanCheckPost(int iClient), fired
  from OnConnectBanCheck once the counts are populated (placed before the
  PrintCheckOnConnect guard so it always runs).
• Updates the include: documents the -1 return contract and declares the
  new forward.

Adaptations vs upstream

• The fork splits comms into separate mute/gag counts, so -1 init and the
  disconnect reset are applied to g_iBanCounts, g_iMuteCounts and
  g_iGagCounts, and the -1 doc note is added to all four natives.
• The fork derives VERSION from SB_VERSION, so the upstream manual
  1.8.0 -> 1.8.1 bump is dropped.
• Forward creation lives in the fork's AskPluginLoad2 (next to g_bLate)
  rather than upstream's AskPluginLoad.

Testing

Relies on plugin-build CI (no local SourcePawn compiler).

🤖 Generated with Claude Code

[Rushaway]

Review: port of sbpp#894 — approve after fixes (pushed as c1c277a)

The port itself is a faithful and, in one respect, better-than-upstream adaptation. Two real bugs fell out of the fork's mute/gag split, both now fixed.

What I verified

• Init/reset: all three fork arrays (g_iBanCounts/g_iMuteCounts/g_iGagCounts) use = {-1, ...} at declaration and are reset to -1 in OnClientDisconnect_Post. No pre-existing OnClientDisconnect* callback was displaced.
• Forward: created exactly once in AskPluginLoad2 (correct for the fork — upstream has no g_bLate there), ET_Ignore, Param_Cell matches forward void SBPP_CheckerClientBanCheckPost(int iClient) in the include. Call_StartForward/Call_PushCell/Call_Finish are correct. Placement is better than upstream: it fires before the if (!g_bPrintCheckOnConnect) return; guard, so servers with PrintCheckOnConnect 0 still get the callback — upstream fires it after the print block, where that guard doesn't exist yet but is a latent hazard.
• Include: forward decl matches the impl; forwards need no MarkNativeAsOptional, and the four existing entries are untouched. The file's pre-existing UTF-8 BOM is unchanged (upstream's PR strips it; not porting that is the right call — it would be unrelated churn, and upstream also drops the trailing newline, which this PR correctly does not).
• No regressions: no in-tree consumers of the checker natives (only a changelog mention in sourcebanspp.inc); no merge residue, no unused vars, no VERSION bump needed since the fork uses SB_VERSION.

Bugs found and fixed

1. SBPP_CheckerGetClientsComms returned -2, not -1. The fork's comms native is g_iMuteCounts[client] + g_iGagCounts[client]. With both halves initialized to -1, the documented "or -1 if not yet available" contract that this PR adds to the include was violated for the one native most likely to be called — callers doing if (SBPP_CheckerGetClientsComms(c) == -1) would silently fall through. Now returns -1 if either half is unavailable.

2. Negative commcount could produce bogus admin warnings. OnConnectBanCheck assigns the mute/gag counters only inside optional if (results.FetchRow()) branches. Previously a short result set left them at 0 (harmless); with the new -1 sentinel they'd stay -1 while g_iBanCounts was populated, making commcount negative — and else if (commcount) is truthy for -1/-2, so admins would see a "Comm Warning" with a negative count. Both counters are now cleared to 0 as soon as the check is known to have completed, so every post-check value is >= 0 and the -1 sentinel only ever means "not checked yet".

Note, not fixed (pre-existing)

The four natives take GetNativeCell(1) and index the arrays with no bounds check; an out-of-range client index from a consumer plugin is an array-bounds error rather than a clean native error. Unchanged by this PR, so left alone.

CI

Compile SourceMod plugins passing on c1c277a.