Consume Ledger target profiles instead of carrying target values in Populace

[MaxGhenis]

Context: Populace currently has structured target machinery, but target values can still arrive through generated registry artifacts and transitional target-surface extraction. Populace should select Ledger target profiles and resolve values from Ledger facts.

Need:

• A TargetRegistry construction path from Ledger profile artifacts.
• Country content that selects target profiles and solver settings without storing observed target values.
• Structured identifiers for source, geography, measure, dimensions, period policy, and model binding. This should build on Persist structured target fields in the US target surface (geography/source/variable/breakdown) #57 rather than relying on display strings.

Acceptance criteria:

• Populace country content contains no target values.
• TargetRegistry can build from a Ledger profile artifact pinned by version.
• The release manifest records the Ledger profile version and source provenance.
• The dashboard and diagnostics use structured fields as primary identifiers.

[MaxGhenis]

The Ledger side of this shipped in PolicyEngine/ledger#73 (design settled in PolicyEngine/ledger#71: facts-only store — publisher projections are facts typed assertion: source_projection; PolicyEngine-computed aging lives here in populace).

What's now available to build against:

• ledger build-consumer-artifact --facts <bundle> --profile <id> --out <dir> produces a reproducible directory: consumer_facts.jsonl + embedded target profiles + per-target coverage diagnostics + a manifest with content hashes. Pinning the manifest hash in build config gives the release-manifest reproducibility this issue and Ledger facts are unversioned in the build manifest — a release's target values are not reproducible #271 ask for.
• policyengine_ledger.load_consumer_artifact(dir).resolve(profile_id, {"type": "tax_year", "value": 2025}, alignments=...) returns resolved target rows with basis, fact_period, requested_period, assertion, value, unit, and full lineage — a TargetRegistry source with no database access and no copied values.
• The period contract is enforced at resolution: consuming a fact at a period other than its reference period raises PeriodContractError unless populace passes PeriodAlignmentDeclaration(model_id=..., model_version=..., parameters=...). Ledger records the declaration and returns the published level; populace applies the transformation. This makes the Cross-check: Populace US 2024 net income & tax ~37–43% below Enhanced CPS (benefits match) #212 failure class — SOI dollar levels calibrated un-aged at a later build year — impossible to hit silently.

Populace-side scope this implies:

1. Artifact consumption: build the TargetRegistry from a pinned consumer artifact (this issue's acceptance criteria map 1:1 to the artifact contract).
2. Reference aging model: one named, versioned implementation (e.g. cbo_growth_factor_aging) consuming CBO growth-factor facts from the same artifact; its model_id/model_version are the alignment declaration. Bumping its version changes no Ledger fact and no artifact hash — only populace build outputs.
3. Basis-aware diagnostics: carry basis through calibration diagnostics so "missed a published fact" and "missed an aged level" are distinguishable.
4. Period-aware transformation needed for SOI EITC-by-AGI calibration targets #116 becomes the first user: SOI EITC-by-AGI levels aged to the build year under the declared model instead of applied un-aged. Geography vintage translation (Translate old-vintage CD targets to current district geography #205) follows the same declared-transform pattern.

[MaxGhenis]

Implementation up in #287: pinned artifact consumption (manifest-hash verification, provenance recorded in build + release manifests — also addresses #271), hard period-contract enforcement with auditable waivers (#212 guard), and aging as the named cbo_growth_factor_aging v1.0.0 model recording alignment_model_id/alignment_model_version on every aged target (#116's SOI dollar targets are the first user). Duck-typed against the ledger contract per this module's existing design — no runtime dependency on policyengine-ledger.

[MaxGhenis]

Resolved by #287 (merge commit 2c93936 on origin/main), the Populace side of the Ledger facts-only transition (PolicyEngine/ledger#71, shipped in PolicyEngine/ledger#73 / merge e462f28). Populace now resolves fiscal target values from an external Ledger fact feed and carries no embedded target values.

Evidence on current origin/main:

• compile_us_fiscal_target_registry(facts, ...) in packages/populace-build/src/populace/build/us_runtime/fiscal_targets.py:723 takes the Ledger consumer facts feed as its first argument; its docstring reads "Resolve US fiscal targets from an external Ledger fact feed." Values enter through facts, not literals in Populace.
• The country package's us/fiscal_target_references.json carries references, not values: each row is a pointer such as {"ledger_source_record_id": "jct.tax_expenditures.cy2024.salt_deduction.revenue_loss", "measure": ..., "period": 2024, "value_operation": "identity"}. A repo check confirms no "value" field appears anywhere in target_references, and the file constrains allowed_value_operations to ["identity"] — Populace may pass a Ledger value through but not embed or override it.
• The facts feed is loaded through the pinned, hash-verified Ledger artifact loader load_ledger_consumer_artifact (packages/populace-build/src/populace/build/ledger_artifact.py), which the release tool consumes at tools/build_us_fiscal_refresh_release.py:4636, so the resolved target surface is provenance-tracked (see the sibling fix in Ledger facts are unversioned in the build manifest — a release's target values are not reproducible #271).

The spec.value arithmetic elsewhere in fiscal_targets.py (uprating factors, CHIP = combined − Medicaid) operates on values already resolved from the feed — derivation, not carrying.

Both prerequisites are merged (PolicyEngine/ledger#73 and populace#287) and the build reads target values from consumer facts with no embedded target values remaining. Closing as done.