Publish Chronicle package IDs in calibration diagnostics targets

Context

PolicyEngine/calibration-diagnostics#156 adds direct Chronicle links to individual calibration-target details. The published calibration_diagnostics.json target rows currently include a human-readable source citation and several Chronicle lineage fields, but not the stable Chronicle source-package ID.

Without that ID, downstream consumers have to infer package identity from citation prose. That has already produced two classes of bug:

• alternate citation spellings for the same source fail to resolve;
• a versioned table can resolve to the wrong source-package vintage.

The frontend now contains a compatibility resolver for existing releases, but citation parsing should not be the long-term contract.

Why this belongs in Populace

Populace produces and publishes calibration_diagnostics.json, so it owns the downstream artifact schema. Chronicle owns the package identifier and should expose it through the consumer/resolution metadata; if that field is not currently available to Populace, this issue should track the corresponding Chronicle dependency rather than asking downstream UIs to reconstruct it.

Proposed contract

For every source-backed calibration target, publish a stable field such as:

{
  "metadata": {
    "chronicle_package_id": "soi-table-2-5-eitc-agi-children-2023"
  }
}

Naming is open to source_package_id if that is the canonical Chronicle field, but the value must be the exact, vintage-preserving package identifier—not a display label or a value inferred from the citation.

For synthetic or non-Chronicle targets, publish null or omit the field according to the existing metadata conventions.

Acceptance criteria

• Source-backed target rows in newly built calibration diagnostics publish the exact Chronicle package ID.
• Historical and current source vintages produce distinct IDs where Chronicle has distinct packages.
• Artifact validation checks that a published package ID exists and is consistent with the target's resolved Chronicle fact/source record.
• Any target derived from multiple Chronicle packages has an explicit representation rather than an arbitrary single ID.
• The package ID is preserved through the calibration-diagnostics API response.
• PolicyEngine/calibration-diagnostics#156 can prefer this field and retain citation parsing only as a compatibility fallback for older releases.

Chronicle dependency, if needed

If Chronicle's consumer artifact does not currently carry package_id alongside resolved fact lineage, open/link a Chronicle issue to add it at that boundary. Populace should consume the authoritative ID rather than maintain a second source registry.

Start at the calibration_diagnostics.json producer and the calibration-diagnostics API response, then inspect whether Chronicle resolution metadata exposes an authoritative package ID. Done means source-backed rows preserve exact vintage-specific IDs, validation checks their consistency, non-Chronicle and multi-package targets follow an explicit convention, and older releases remain compatible.