Fact provenance needs an asserting principal and root-artifact lineage so the microdata-derived-fact prohibition is enforceable

[MaxGhenis]

Follow-up from the raw-microdata identity ADR (#222, gate round 3): the prohibition "no fact derived from raw microdata by Chronicle or a consumer enters Chronicle" is stated but not enforceable, because fact provenance today is free-form source metadata (source_name, source_table, source_file, extraction_method, …) with no asserting principal, no reference to the registered artifact the value came from, and no transitive root. validate_fact therefore cannot tell a publisher-published aggregate from a consumer aggregate that was derived from microdata through one or more intermediate artifacts.

Proposal

1. Add to fact provenance (not to fact identity — identity payloads stay byte-identical):
   • asserted_by: the publisher id that asserted the value (the same id the source registry uses).
   • root_artifacts: the registration tuples {source_id, package_id, year, sha256, filename} of every artifact the value ultimately comes from, transitively through derived artifacts.
2. validate_fact rejects a fact whose root_artifacts include a kind: microdata_release registration unless asserted_by is that release's publisher (the publisher-published-aggregate exception from the ADR), and rejects a fact with no asserted_by once the field is required.
3. Source packages populate both fields from the manifest (publisher, registration tuple of the parsed artifact); derived artifacts carry their inputs' roots forward.
4. Tests: a consumer-computed aggregate rooted in an FRS registration is refused; a DWP-published FRS table is accepted; a chain through an intermediate artifact is refused.

Depends on #227 (registration identity) and the epoch work (#228) for the provenance surface. The ADR (#222) references this issue as the enforcement mechanism for its decision point 3.