fix(coop): harnessEquip/harnessSetArmor enforce the real craft-capacity gate

[NonPolynomialTim]

Follow-up to #120 (merged). #120 landed the mid-battle-resume fix plus the harness "real button" hardening (start/resume/inline callers). This PR carries the one commit that missed the #120 merge window: the harness craft-capacity gate fixes. Rebased on current origin/main.

What

The harness* fidelity audit found two methods that bypassed the client-side capacity gate their real button enforces — and which the SHARED host validators do not re-check — so a test could reach an over-capacity craft no player can (the same class of hazard as the resumeCampaign() lobby bypass #120 fixed):

• harnessSetArmor called applyArmorSelection() directly, skipping lstArmorClick's Craft::validateArmorChange (STR_NOT_ENOUGH_CRAFT_SPACE).
• harnessEquip called equipSelectedWeapon() directly, skipping lstWeaponsClick's four capacity gates (cargo / HWP / storage_1 / storage_2).

Extracted lstWeaponsClick's capacity checks into a pure CraftWeaponsState::equipCapacityError() — one source of truth, no state-stack side effects — used by both the UI handler and harnessEquip; added the matching validateArmorChange guard to harnessSetArmor. Both now refuse an over-capacity change exactly like a player. test_shared_equip2 stays green.

Not in this PR

The deeper engine half — the SHARED host validators (craftRearmValidate / soldierArmorValidate in SharedEcon.cpp) not re-checking craft capacity, so capacity is client-only-enforced in SHARED — is a real latent bug tracked in #121.

🤖 Generated with Claude Code

[NonPolynomialTim]

Superseded by #123, which fixed issue #121 (host-side craft-capacity re-validation) and in doing so redid this PR's harness gate fixes with a better, shareable equipCapacityError(Mod*, Craft*, ...) and a bypassGate/blockedBy harness API. Content here is a strict subset of #123 (and its old harnessEquip/harnessSetArmor signatures would now conflict with #123's TestServer callers). Nothing to add — closing.