Extract runtime reward definitions and replace hardcoded grants

[throgsoft]

Scope

Reward pool contents are now extracted from the installed packages instead of hardcoded. Refactors upstream grant paths (season pass claims) to use the resolver.

Removed	Replaced by
Legendary/exotic engram item pools and class armor lists (season_pass_reward_catalog.h)	Extracted reward pools and eligibility conditions
Planetary material bundle hash list	Extracted material wrapper pool
fixed Season Pass armor stat rolls (web_service_record_actions.cpp)	Socket overrides extracted from each pass row
Class package, bundle and engram special cases, and the separate season package encoder and staging path	One record-reward grant path, the same one Triumph rewards use

Extracted from packages:

• Reward pools, members, and references to nested pools
• Quantities, weights, weight modifiers, conditions and socket overrides
• Item wrappers: pools, category selections, and whether they can be acquired

Behavior changes:

• Season pass perks set account flags when seasonal XP is published
• Conditions run in the existing unlock-expression evaluator, moved from vendors/ to state/unlocks.

Native acquisition order

Inspection of the installed build's native wrapper path confirms that selection and acquisition are interleaved. Each selected item completes acquisition before the next draw evaluates its conditions. An automatic child wrapper opens before its own acquisition flag is set, so later parent draws can observe flags acquired by earlier children. This is the ordering contract for wrapper resolution; acquisition flags must not make an otherwise empty top-level draw eligible.

Validation

On a fresh database install, I used db key character_slot = -1, bank = 6, slot = 38, lane = 0, value = <desired XP> in the unlocks table to set xp. Tested all season pass reward claims in-game.

NOTE 1: Failed claims will log instance_capacity if the target buckets are full. The fix is to implement overflow routing and the FIFO eviction policy for the postmaster bucket which remains as separate follow-up work.

NOTE 2: I found no package data establishing which rewards the rabbit or cat statues grant. dreambane_engram is a candidate for rabbit rewards but I could not verify that association natively

NOTE 3: Reward-roll seeds remain ephemeral. Durable seed storage is deferred with overflow/FIFO work. The inherited season-pass issue where claiming the planetary materials package can make other policy rewards appear full is also outside this PR; no speculative ring-buffer or refresh workaround is included.

[stanuwu]

• cache_investment_records.cpp:136 -> unused slots are 0, which is not in opcode enum and will fail
• consume_deferred tries forever if grant fails, row is not removed
• package_item_rows.cpp:170 -> discards / fails without log
• grant_progress_flags walks every pass row on every XP grant
• kGearsetItemField, kGearsetItemRowClass and kGearsetItemStride have no consumer left and no TODO
• stale refusal reasons on eight failure paths, kDrawCapacity 64 exceeds the grant array and fails
• Bank capacities are all 32768 which is megabytes of excess allocations that may not be required

[throgsoft]

cache_investment_records.cpp:136 -> unused slots are 0, which is not in opcode enum and will fail:

• Changed the decoder to decode only the populated condition and socket slots, unused slots are checked against defaults instead of being decoded as instructions.

consume_deferred tries forever if grant fails, row is not removed:

• Unresolvable rewards are now retired and logged, while temporary failures remain queued. Missing catalogs, unmet unlock conditions and inventory capacity are retryable
• A notification encoding failure no longer leaves an otherwise successfully committed reward blocking the queue, inventory changes and removal of the pending reward remain atomic

package_item_rows.cpp:170 -> discards / fails without log:

• Added diagnostics for reward loading, validation and publication failures, including counts for discarded entries and unbound acquisition flags.
• Unsupported reward data stops retrying without blocking unrelated item domains.

grant_progress_flags walks every pass row on every XP grant:

• Now only walks when XP crosses a rank boundary or an earlier reconciliation is still owed. Ordinary XP grants within the same rank no longer scan the pass.
  • Also reconciles on character selection so startup does not require another XP grant to award already-earned perks

kGearsetItemField, kGearsetItemRowClass and kGearsetItemStride have no consumer left and no TODO:

• Removed all three unused constants

stale refusal reasons on eight failure paths, kDrawCapacity 64 exceeds the grant array and fails:

• Added specific refusals at failing operations and cleared reasons on successful resolution
• Checked actual selections and item-grant appends independently. The limit includes selections that produce no item. item output remains bounded by the existing grant publication capacity.
• Added a diagnostic for each limit

Bank capacities are all 32768 which is megabytes of excess allocations that may not be required:

• Replaced the blanket capacities with bounds based on measured installed counts
  • Tried to match the existing catalog and cache design but maybe dynamically sized banks would be good to support custom packages

Also:

• Rebased
• Moved the response-capacity check before drawing a queued reward, so insufficient space in a combined response does not cause an unnecessary draw and retry

[throgsoft]

Also addressed:

• automatic nested wrapper opening and acquisition flag ordering
• reward conditions in the installed data that exceeded the evaluator’s previous stack size limit and prevented affected wrappers from resolving
• empty wrapper draws incorrectly succeeding solely because the wrapper’s own acquisition flag was set.
• repeated draws of the same stackable item are rejected as duplicate grants and their quantities are now combined before preparation (edge case that I don't think can happen in installed data)
• pending perk reconciliation being lost after a transaction rollback. pending state now rolls back