USDA FY2025 monthly manifest records the FY69-to-current package's 2024 R2 key

What

db/data/usda_snap/fy69_to_current/manifest_fy2025_monthly_source_package.yaml (package usda-snap-fy2025-monthly-state-caseloads, vintage 2025, file snap-zip-fy69tocurrent-6.zip, sha256 3eee0916…4101abe) records this storage.r2 key:

raw/usda_snap/usda-snap-fy69-to-current/2024/3eee091653335a00a80c6fe76b84904b309dddba0c8b63a256b7e079e4101abe/snap-zip-fy69tocurrent-6.zip

That is the sibling package's object (manifest.yaml, package usda-snap-fy69-to-current, vintage 2024, same bytes). The canonical location for the FY2025 entry is raw/usda_snap/usda-snap-fy2025-monthly-state-caseloads/2025/<sha256>/snap-zip-fy69tocurrent-6.zip, so the entry's recorded key disagrees with its own package and year.

How it was found

Sol's gate review of #226 (round 1). Verified by reading both manifests. chronicle inventory-artifacts --root db/data/usda_snap/fy69_to_current --manifest manifest_fy2025_monthly_source_package.yaml reports the entry valid (inventory checks bytes and locator shape, not the key's package/year), and the root sweeps do not visit named manifest_*.yaml files at all today (#226 fixes the sweep; once it lands, publish-raw over this directory will refuse the entry as recorded_r2_key_disagrees_with_country_prefix).

What to decide

The bytes are identical, so the question is provenance shape, not content: either (a) publish the same bytes under the FY2025 package's own key and record that block (keeping the FY69 one untouched), or (b) decide that a package may point at another package's content-addressed object and teach the key check to accept it explicitly. Not changing tracked data inside #226.

Compare db/data/usda_snap/fy69_to_current/manifest_fy2025_monthly_source_package.yaml with the sibling manifest.yaml, then run chronicle inventory-artifacts --root db/data/usda_snap/fy69_to_current --manifest manifest_fy2025_monthly_source_package.yaml. Determine whether the FY2025 package should receive its own object key or cross-package references should be supported; done means the provenance policy is decided and the manifest and validation behavior agree.