Shelved PR 274 pvf input hardening

Shelved: PR #274 — Consolidated PVF input-hardening guards

State: Ray-shelved 2026-07-03 (Build 89 pick round). PR #274 was closed without merging; nothing from it is in Build 88/89.

WHAT

Adds a set of additive input-validation guards to several server-side network entry points (PVFunctions), so a forged, too-short, or non-player message is rejected with a WARNING log instead of throwing a script error or being trusted. It covers attack-wave detail messages, AI-commander donations, GUER FOB-structure builds, the RequestSpecial handler, and site-clearance requests. Legitimate calls are unaffected — this is a pure anti-forge/robustness hardening pass with no gameplay change.

WHERE

• PR: #274 — "[fable] PVF input hardening — reject malformed/non-player payloads (lanes 136/140/141/142)".
• Branch / head commit: fable/pvf-input-hardening @ d5c00d4050ff0724f97489a4225b583fad50d641.
• Flag (if any): No flag / always-on. Pure additive input rejection; no gameplay behaviour changes.
• Files touched (server PVFunctions): AttackWave.sqf (array/count guards on ATTACK_WAVE_DETAILS + CLIENT_INIT_READY), RequestAIComDonate.sqf (isPlayer on donor), RequestFOBStructure.sqf (isPlayer on builder), RequestSpecial.sqf (type/count guard before Spawn HandleSpecial), RequestSiteClearance.sqf (isPlayer on requester). Mirrored Chernarus + Takistan.

WHY SHELVED

On 2026-07-03 Ray's pick was "no" — he chose not to fold these consolidated PVF input-hardening guards into this round.

Important context — the security-hardening family stays PARKED-OPEN, not closed. This PR belongs to the ongoing "security hardening" family, and that family remains parked/open exactly as before. PRs #203, #205, #207, #208, #209, #210, #217, #255, #275, #288, #336, #338, and #399 stay open/parked and are unaffected by this round. Only #274 and #278 were explicitly declined now. Shelving #274 is a "not folding this one now" decision, not a rejection of the security lane as a whole.

HOW TO REVIVE

• Recover from branch fable/pvf-input-hardening @ d5c00d4050ff0724f97489a4225b583fad50d641; the guards are additive exitWith checks at the top of each PVF and re-land cleanly if the underlying files haven't diverged.
• This is a "Ray chose not to fold now" case, not a design flaw — it can simply be re-offered in a future pick round alongside (or folded into) the still-parked security family.
• Before re-landing, re-verify each guard against the current PVF signatures (payload shapes for ATTACK_WAVE_DETAILS, RequestFOBStructure index-4 player, etc.) since those files may have moved.
• Consider bundling with the sibling #278 (build/repair authority guards) so the security lane lands as one coherent set rather than piecemeal.