test: stop pinning rustledger's directive hash in snapshots

[robcohen]

The coupling

test_get_ledger_data.json pinned 62 literal SHA-256 digests. Those are rustledger's directive-identity hash — an implementation detail of a separate repo, covered by its own tests. Nothing about rustfava's behaviour is asserted by their exact values. Pinning them means every change to that hash function turns this suite red and forces a lockstep regeneration, which is exactly what rustledger#1984 just did.

The snapshot machinery already tries to normalise hashes. It missed these because both patterns require the underscore:

_hash": ?"[0-9a-f]+

That matches entry_hash and misses the bare hash key inside meta — so one hash was normalised and the other 62 leaked into the file. Anchoring on the opening quote fixes it without touching entry_hash; requiring a full-length digest keeps user metadata that happens to be called hash from being silently swallowed.

Verification

test_get_ledger_data now passes against both components, which it could not do before — they produce different digests for identical input:

	pinned v0.21.0 release asset	component built from rustledger main
before	pass	fail
after	pass	pass

Full suite against the pinned v0.21.0 asset: 667 passed, 1 skipped.

Sabotage-checked, so this is a normalisation and not a blanket that hides everything:

sabotage	result
change a lineno in the snapshot	still FAILS ✓
short (non-digest) hash metadata value	survives redaction untouched ✓
entry_hash under the new pattern	unaffected ✓

What this does not fix

Three snapshots still differ against rustledger main. All three are genuine behaviour changes, not churn, and I verified each is a correctness improvement:

• test_api_errors — a spurious interpolation failed: multiple postings missing amounts... error is gone. I ran beancount directly against that fixture: it reports 3 errors and no interpolation error, so main now matches beancount and the released component was wrong.
• test_serialise_entry_types — number-value metadata "10" → "20". The fixture is number-value: 10 + 10, and beancount evaluates metadata arithmetic, so 20 is correct.
• account_report_off_by_one_journal and test_serialise_entry_types — 101.0 → 101, -1.0 → -1. Every source literal involved is an integer (1 COM {100 USD}, price 101 USD), so the trailing zero was spurious.

These cannot be fixed in this PR: their expected values genuinely differ between the pinned release and main, so any single committed value is red on one side. I confirmed that empirically — regenerating all four against main makes the same four tests fail against v0.21.0, just inverted. They belong in whichever change advances RUSTLEDGER_VERSION.

🤖 Generated with Claude Code

https://claude.ai/code/session_018bGRsKA42peqSnz4VMreBG