feat: equipment potential options — storage + granting

[ipdae]

Summary

Adds the equipment potential option (장비 잠재 옵션) feature to lib9c, as an independent latent-option layer stored directly on Equipment (rather than a separate account state). This PR covers storage + granting; option interpretation/application to stats/CP is intentionally a later phase.

Design plan: 장비 잠재 옵션 — 부여 구현 계획 (lib9c) · Reference spec: 장비 잠재 옵션 시스템 기획 v1

Commits

1. Storage layer — EquipmentPotential + PotentialOptionSlot with self-contained List serialization (its own version, independent of ItemBase.SerializationVersion). A single Potential field is appended to Equipment as an optional trailing field (index 23); EQUIPMENT_FIELD_COUNT is kept, so pre-existing equipment (23-field list or legacy Dictionary) deserializes to EquipmentPotential.Empty (no migration). Each slot stores only (int OptionRowId, long Value), neutral to how it is later applied. The 7 equipment subclasses inherit serialization unchanged.

2. Granting pipeline

• EquipmentPotentialGradeSheet (grade → slot count + material cost) and EquipmentPotentialOptionPoolSheet (weighted option pool per equipment sub type), with CSVs.
• PotentialHelper.Roll — deterministic weighted selection from the pool (filtered by sub type) with an inclusive value roll.
• GrantEquipmentPotential action — validates ownership / sub type (Weapon/Armor/Belt/Necklace/Ring; Aura/Grimoire excluded) / grade, consumes the per-grade material cost, rolls the grade's slot count, and stores the result via Equipment.SetPotential. Re-running re-rolls and re-charges (does not accumulate slots), matching the spec's cube re-roll loop.

Testing

• Storage: present/absent round-trips across the model, direct Equipment, and the production ItemFactory.Deserialize path for every equipment sub type, plus legacy List (23-field) and Dictionary formats.
• Grant: success, insufficient material, ineligible sub type, grade without slots, item not owned, re-grant overwrite + recharge, determinism, and a golden roll-output test that locks the algorithm against consensus-breaking changes.
• Action registered in ActionEvaluationTest (MessagePack round-trip).
• ✅ Full suite: 3718 passed / 6 skipped; build + docs checks pass.

Both commits were reviewed by an automated code review; findings addressed.

⚠️ Deployment notes

• The Equipment serialization gains a trailing field unconditionally (same pattern as prior added fields like Exp/IconId). This must ship in a coordinated release / hardfork so mixed-version nodes don't diverge on state root.
• The two new table sheets must be present in on-chain state (genesis / PatchTableSheet) before GrantEquipmentPotential is activated, or the action's sheet load will throw.

Out of scope (follow-up)

Option resolution/application — turning stored (optionRowId, value) into stat effects via CharacterStats (rune-style modifier layer) and CPHelper, plus content-limited / skill effect kinds.

🤖 Generated with Claude Code