Fix receipt and callback digest split from a changing proposal

[aruintelligence]

Finding and fix

A stateful JavaScript getter made dispatchAction hash a first proposal for its receipt, then snapshot the caller object again and pass a different body to the host callback. The allow and approval-required local paths both returned dispatched with a receipt digest that did not identify the callback payload.

The boundary now canonicalizes the caller once, validates the serialized value, and uses that same frozen proposal for planning, policy rechecks, approval, receipt, and callback.

Reproducible evidence

• Two changing-getter cases, checked-in current report, and separately coded Python oracle.
• A selected source substitution reintroduces the second read and splits both cases. It leaves the static 384-vector and eight-case tuple suites unchanged; all ten selected substitutions differ across the combined finite suites.
• New interactive before/after page and links from the existing proof pages.

Verification

Focused Node and Python checks, 13-case cross-runtime comparison, local link and deployment checks pass. The broad local Node 24 suite has one pre-existing TypeScript fixture failure (test/consumer-types.mts); GitHub CI uses Node 22.

Limits: Project-authored local fixtures and selected mutations, no provider effect, outside witness, or formal proof of production safety.