Persist installed registry provenance and pin metadata

[StatPan]

Summary

Persist enough metadata about the installed registry release so future status, diff, regenerate, and verification workflows know exactly what local specs are based on.

Part of #5. Supports #14, #15, #16, and #17.

Current gap

datapan init and catalog install datapan-registry install the registry and preserve release evidence, but the local project needs an explicit provenance record for the installed registry snapshot. Without that, stale checks and update-impact workflows must infer too much from filenames or release evidence.

Desired behavior

Write and maintain a local registry provenance file, for example:

.datapan/registry.json

or:

.datapan/registry-install.json

It should include:

• installed registry path;
• registry release tag/version;
• release API URL and asset URL;
• registry artifact digest if available;
• install timestamp;
• release manifest path;
• preserved evidence paths;
• whether the user pinned a release or installed latest;
• source mode: embedded, default installed, env override, explicit path.

Acceptance criteria

• datapan init and datapan catalog install datapan-registry write provenance metadata.
• datapan status --json and datapan doctor --json read and expose it.
• Custom registry paths and env overrides are clearly distinguished from installed default registry state.
• Reinstall/update workflows preserve or update provenance deterministically.
• Tests cover latest install, pinned release install, explicit registry path, env registry path, and missing provenance fallback.

Notes

This is the bookkeeping layer that lets the CLI treat registry updates like dependency updates instead of opaque file replacement.

[StatPan]

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

Installed registry provenance should identify the registry release bundle and preserved release artifacts, not only the registry JSON path. datapan-registry releases are manifest-driven and include schemas, provider index, coverage, verification, runtime evidence growth, route disposition, source-scoped reports, and registry impact plans. The local provenance file should record enough release/asset/manifest/evidence metadata for CLI status, stale checks, impact-plan consumption, regeneration, and verification planning to be reproducible.