fix(verify/worldid): require a resolvable adcp-go version for external import

[bokelley]

verify/worldid is a separate module meant to be imported by external repos (scope3data/rtdp, for the World Ads operator path), but its go.mod required adcp-go v0.0.0 — a placeholder that only resolves in-repo via the replace => ../... External consumers ignore the replace, so the require failed to resolve and the module couldn't be imported.

Pins the require to the real pseudo-version of the module's commit; keeps the replace for in-repo local dev (so adcp-go CI still builds against local root).

Validated: a scratch module that replaces only verify/worldid to local now resolves adcp-go root from the proxy and builds — confirming external import works.

🤖 Generated with Claude Code

[aao-ipr-bot]

Correct fix for a real external-import break. The placeholder v0.0.0 only ever resolved through the in-repo replace, so any external consumer (scope3data/rtdp on the World Ads operator path) hit an unresolvable require — pinning to a proxy-resolvable pseudo-version is the right shape.

Things I checked

• Pseudo-version is real, not invented. v0.0.0-20260610020654-c0720af293c1 decodes exactly: commit c0720af293c1 committed 2026-06-09T22:06:54-04:00 → 20260610020654Z UTC, hash prefix matches c0720af293c19930135a8cce44c5035bf38ab4ad. The format is valid and the commit is on main, so external proxies can resolve it.
• replace github.com/adcontextprotocol/adcp-go => ../.. is preserved (verify/worldid/go.mod:14). In-repo CI still builds against local root; the require pin only matters when the replace is dropped — i.e. exactly the external-import case.
• Conventional-commit type is correct: fix(verify/worldid):. No exported symbol removed/renamed, no wire change, no breaking marker needed.
• No source diff, no schema/types touch, no tmproto/signing surface. go.mod-only.

Follow-ups (non-blocking — file as issues)

• This pin is a moving target: it points at one specific commit, not a tag. Every time an external consumer needs newer root code they'll re-bump it by hand, and there's no CI guard that the pinned version stays resolvable. A tagged release of the root module, or a freshness check, would make this self-maintaining. Not this PR's job.

LGTM.