Track jokers / improve telemetry

[adilw3nomad]

This PR introduces some new log events, intended to track jokers being bought/sold during a match, and for how long.

---

How it appears in the log file

INFO - [G] 2026-03-01 09:33:49 :: TRACE :: MULTIPLAYER :: Client sent message: {"jokers":[{"cost":4,"ante_acquired":1,"key":"j_zany","edition":"none","seal":"none","held_at_end":true,"hold_duration_antes":1,"source":"shop"},{"cost":5,"ante_acquired":1,"ante_removed":1,"key":"j_wrathful_joker","edition":"none","seal":"none","held_at_end":false,"hold_duration_antes":0,"source":"shop","removal_reason":"sold"},{"cost":7,"ante_acquired":2,"ante_removed":2,"key":"j_mp_bloodstone","edition":"none","seal":"none","held_at_end":false,"hold_duration_antes":0,"source":"shop","removal_reason":"sold"}],"ruleset":"ruleset_mp_blitz","ante_reached":2,"won":false,"gamemode":"gamemode_mp_attrition","deck":"Red Deck","stake":1,"action":"matchJokerReport"}

---

I'm following this up with a PR to accumulate and store this data in the API server, however this PR works in isolation as it has no affects on behaviour.

I've tested it locally with no issues.

[stephenkirk]

Thanks for putting this together - the lifecycle data would be genuinely useful. A couple of thoughts before this goes further:

Inline: on_joker_acquired only hooks buy_from_shop

The source parameter accepts "shop", "booster", "tag", "other" – but the only call site is in the buy_from_shop override, so boosters, tags, and other acquisition paths are never tracked. Same gap on the removal side: on_joker_removed only hooks sell_card, missing destructions (Madness, perishable expiry, etc.). The lifecycle data will be incomplete in ways that aren't obvious from the report schema.

Broader: could this piggyback on the existing gameplay signals instead?

We already send soldJoker and boughtCardFromShop to the server in real time. If those messages were enriched with the metadata you're collecting here (key, edition, cost, ante, source), the server could reconstruct the same joker lifecycle from the event stream, without maintaining a parallel client-side tracker that has to independently hook every acquisition and removal path. The server becomes the single source of truth, held_at_end and hold_duration fall out naturally (acquired with no corresponding removal = held to end), and you don't need the end-of-match report at all.

That approach would also make it easier to extend coverage incrementally – each new event type (booster open, tag redeem, Madness destroy) enriches the stream automatically once it exists, rather than needing matching on_joker_acquired/on_joker_removed hooks wired up in a second system.

[adilw3nomad]

Thanks for having a look at it Stephen! You're right; it doesn't consider other forms of acquiring/removing jokers.

I'll have a closer look at the soldJoker and boughtCardFromShop events and see how it can work that way; I agree with the idea of the server being the single source of truth 👍