Verify EFFECTIVEDATE on Bridge-built bank vouchers

[lamemustafa]

Problem

Bridge writes EFFECTIVEDATE on every Payment, Receipt and Contra it builds. verify_import never fetches it. So a voucher whose effective date Tally rewrote, or an operator later edited, still reports posted_verified. The amendment compare-and-swap (agent_import_amend.rs) has the same blind spot.

What is now known

The blocker was that nobody knew whether the verification collection returns the element at all; requiring an element that never comes back would refuse every verification. #467 records one live read, on licensed 7.1 Silver in the synthetic lab: the §9.8 verification request with EFFECTIVEDATE added to FETCH returned it with TYPE="Date", equal to DATE, on a Bridge-built Receipt, Payment and Contra.

The same read showed that PARTYLEDGERNAME must not be added the same way. It returns a bank ledger rather than the written counterparty.

Proposed change

1. Add EFFECTIVEDATE to render_import_verification_read's FETCH.
2. Carry it through parse_agent_changed_rows. That parser is shared with the public voucher read tools, so decide whether it becomes part of their output or stays internal to import verification.
3. In voucher_diffs, for bank types only: a returned value that differs from the written date is a diff (effective_date). An absent element is not a diff, and is reported as "effective date not observed", so a release that doesn't return it degrades to today's behaviour instead of refusing every verification.
4. The compare-and-swap picks this up through voucher_diffs.
5. Capture a byte-exact verification response carrying the element as the fixture (the request changes, so existing request-matched simulator fixtures need their paired captures refreshed), and remove the limit paragraph in TALLY_PROTOCOL_REFERENCE.md.

Not in scope: Journal, which renders no EFFECTIVEDATE.