[Feature] V2: write consumer bindings and v1/v2 migration runbook

[collinsezedike]

Summary

V1 and v2 will run side by side, v1 cannot be upgraded in place (no WASM upgrade entry point, no state importer) and cannot rescue its own stranded bonds by moving them to v2. This issue documents and tools the coexistence period.

What to build

• Update docs/src/INTEGRATION.md with a v2 section: how to call the v2 contract (new function signatures from [Feature] V2: implement bonded assertion posting #65-[Feature] V2: implement credit accrual and owner-authorized withdrawal #70), and how the identity of an assertion changes to (contract_id, assertion_id) now that both deployments can independently issue id 0.
• A migration runbook covering: inventorying a v1 deployment (network, contract id, exact WASM hash, token, bond, challenge window, admin, committee, every open Pending/Disputed assertion, since v1 has no public config/version/NextId getter and this must be reconstructed from deployment transactions and events); deploying v2 fresh at a new address (never copying v1 assertion records or moving pooled token balances, every v1 bond stays a v1 liability); routing new assertions to v2 from a recorded cutover point while v1 drains; and retiring v1 operationally once its accepted traffic has drained (leaving it unpaused, since there's no atomic way to block new v1 assertions without also blocking dispute/resolve on ones already open).
• Explicitly document: do not pause v1 during drain. V1's pause blocks both dispute and resolve while leaving finalize callable, which could let a pending assertion's challenge window close without ever having had a real chance to be disputed.
• Update demos/freelance-escrow (or note as a follow-up issue) once v2 is live, since it currently talks to the v1 canonical instance directly.

Depends on

#64-#71 (needs the full v2 interface to exist before it can be documented accurately).

[collinsezedike]

Implemented and merged in #90.