chore(ai): restamp the perf baseline's card-data hash for the scoped provenance

[matthewevans]

#7013 changed card_data_hash from a whole-file digest of card-data.json to a
digest of only the cards default_scenarios() actually plays (46 of 46, as CI
reports). The committed baseline still carries the OLD whole-file value, so the
two sides are produced by different functions and can never agree — every perf
gate run since the merge prints

note: card-data hash changed (e2db8a6d…→d11502ce…) — likely a card-data-driven
trajectory shift, not a cost-per-node regression

on an unchanged workload. A diagnostic that fires unconditionally is worse than
none: the next reader sees "card-data changed" and stops investigating a real
regression.

The new value is the one the merged binary computes on the CI runner, observed
identically on two separate runs against different weekly card pools
(30963718102 pre-merge, 30996886019 post-merge) — consistent with the scoped
subset being stable across MTGJSON vintages, which is what motivated #7013.

Provenance only. Counters, seed, action_cap, sample_count and scenarios are
untouched, so this changes no PASS/FAIL verdict — card_data_hash is
diagnostic and never feeds any_fail().

NOT fixed here, and worth its own change: git_sha reads 64b65e5, a
pull/6777 BRANCH head that was never on main. Measuring at that commit yields
layers_full_eval=4045 against the 3495 recorded here, so the baseline's counters
do not reproduce at the commit they name. Restamping the SHA without
re-measuring would only move the inconsistency.