String year keys in manifest files: crash the {year} templating in source_package.py

Problem

ledger/source_package.py:1735 runs value.format(year=year, filing_year=year + 1) while iterating manifest files: keys. When a manifest uses a non-numeric key (a vintage/release label rather than a year), year arrives as a string and year + 1 raises TypeError.

Two manifests currently trip it:

• cms_nhe/historical_service_source
• ssa .../extracted_targets

Neither loses facts today (NHE builds fully via its column_by_year data years — CY1966–2024, 59 facts; the SSA extracted set is redundant with its numeric 2024 key), but the crash blocks the affected (package, key) builds and will bite the first manifest where a labeled key is the only source of facts.

Related edge, same root: _year_mapping(column_by_year, <label-year>) raises "No source artifact for year ..." for release-label keys with no data column (seen with cbo/individual_income_tax_receipts_2026_02 [2026] and federal_reserve/z1_household_net_worth [2026]).

Suggested fix

Treat non-integer files: keys as labels: skip the {year}-templating path for them (or coerce with an explicit int() guard and a clear "label key, no year templating" branch), and make the per-key build report distinguish "label key, nothing to build" from a real failure.

Found 2026-07-03 while rebuilding the canonical consumer_facts.jsonl for the populace US build.

Read ledger/source_package.py around line 1735, then inspect the files: entries in cms_nhe/historical_service_source and ssa .../extracted_targets. Reproduce the affected package/key builds and verify that non-integer keys avoid year templating, while the per-key report distinguishes a label key with nothing to build from a real failure.