feat(server): audit successful item and currency transactions #162

Context

Depends on the private journal contract in classic#159 and the item identity/provenance work in classic#160.

Classic already counts many item and economy actions, but the aggregates cannot show which item moved, who the counterparty was, why a balance changed, or the ordered before/after state needed for recovery. Instrument the semantic success paths so each completed logical transaction produces one structured journal transaction as well as the existing metrics.

Prime native paths found during the survey:

• pickup, container movement, and drop in player.c;
• object split/merge/insert/decrease/destroy in object.c, where low-level calls currently lack actor/reason context;
• bank deposit/withdrawal and hidden bank balance mutation in bank.c;
• shop payment, bank-funded payment, checkout, and sale in shop.c;
• starting items, treasure, quest-objective grants, generated coins, and trusted Python insertion/removal paths that bypass ordinary floor pickup/drop.

Required coverage

Record one transaction-level event, not one record per unit or internal helper call, for successful:

• acquisition into player custody, ground drop, cross-player/service transfer, and external-container transfer;
• persisted player-item creation/grant, removal, and non-routine destruction, with a semantic reason;
• shop purchase and sale, including item/quantity, total price, and carried-cash versus bank funding;
• bank deposit, withdrawal, and every other bank-balance mutation, with balance before, delta, balance after, currency, and reason;
• operator/scripted item or currency mutation through a reason-aware trusted API.

For each item operation, capture the persistent item/lineage identity, archetype/type and a bounded immutable snapshot, quantity, source/destination, actor/counterparty when known, and provenance before/after. Capture the item before a merge or destruction removes the source object.

Classify routine consumption/ammunition and purely internal same-player reordering explicitly. High-volume gameplay that is not useful for recovery should remain aggregate-only; do not infer semantic events from generic object_destroy() or log stack merge housekeeping.

Correctness rules

• Emit only from an authoritative successful transaction boundary. The existing pickup/drop map events are pre-operation veto hooks and are not evidence of success.
• Use the intent/commit or atomic persistence protocol from feat(server): add a durable private gameplay audit journal #159. A post-success LOG() call alone does not close the crash window.
• Update latest-relinquisher provenance from feat(server): persist hidden player custody provenance on items #160 in the same logical transaction as the custody event.
• Do not double-count a logical shop, bank, or transfer operation through both its generic payment helper and its business-specific wrapper.
• Preserve the current metrics, but add tests that their successful-operation counts agree with committed journal events for covered actions.
• Attach actor and reason context at semantic call sites instead of making low-level object helpers guess.

Acceptance criteria

• The native action matrix lists each covered entry point and assigns one authoritative event producer and reason code.
• Successful pickup/drop records use the actual surviving stack identity after split/merge and never record a vetoed or failed attempt.
• Same-player inventory reordering is not misreported as a custody transfer; nested/external container semantics match feat(server): persist hidden player custody provenance on items #160.
• Every bank-balance write, including bank-funded shop payment, is centralized or otherwise proven to emit exactly one before/delta/after transaction.
• Shop buy/sell and item/currency grants are correlated as one logical transaction rather than unrelated records.
• Crash/restart tests demonstrate reconciliation without item or currency duplication/loss for each transaction family.
• Tests cover partial stacks, merge/destruction, insufficient funds/capacity, vetoes, unpaid shop items, floor overflow, direct grants, and journal-write failure.
• Documentation identifies deliberately aggregate-only item/economy activity and why its volume or recovery value does not justify journal events.

Non-goals

• Recording low-level object lifecycle noise for effects, map teardown, or internal merges.
• Replacing cumulative item/economy metrics with journal scans.