Plan verification runs from registry update impact

[StatPan]

Summary

Use registry diff/impact results to generate bounded verification batches for only the call paths affected by a registry update.

Part of #5. Related to #15.

Current gap

catalog verify plan can plan evidence growth from existing verification reports, but it is not yet tied to registry update impact. After new specs land, users need a direct path from changed metadata to focused verification instead of rechecking unrelated operations.

Desired behavior

Given an old registry, new registry, and optional previous verification report, produce verification batches for:

• newly callable operations;
• endpoint or parameter changes;
• operations that moved into or out of adapter ownership;
• previously verified operations whose call route changed;
• operations with stale evidence after registry update.

Possible surfaces

• datapan catalog verify plan --old-registry OLD --registry NEW --impact REPORT --json
• datapan catalog update data-go-kr --verification-plan --json
• impact report next_steps that point to focused catalog verify commands.

Acceptance criteria

• Plan output distinguishes evidence-growth batches from update-impact batches.
• Generated commands preserve existing bounds such as --limit, --timeout, --workers, provider/host/kind filters, and --exclude-input where appropriate.
• Stable ordering keeps high-value/changed operations first.
• JSON includes reason codes for why each batch exists.
• Tests cover new operation, changed endpoint, changed params, adapter ownership transition, and no-impact cases.

Notes

This completes the loop: registry changed -> impact known -> only affected call paths are verified -> coverage/evidence can be carried forward.

[StatPan]

Cross-repo alignment note after checking StatPan/datapan-registry:

Verification planning should use both registry impact-plan actions and runtime evidence growth artifacts. The registry repo already publishes source-scoped reports/data-go-kr/runtime-evidence-growth.json, validates it against datapan.runtime-evidence-growth.v1, and uses it to track progress toward the 10% runtime evidence target.

For CLI planning, impact-plan actions such as refresh_verification should identify changed paths, while runtime-evidence-growth should identify broader evidence gaps and next planned batches. The CLI should make both visible instead of treating catalog verify plan as a standalone planner disconnected from registry release artifacts.