Expose OSMHeader provenance metadata from BlobReader

[brawer]

Summary

• BlobReader now parses the OSMHeader block's writingprogram, source, and osmosis_replication_timestamp fields by hand (neither osm_pbf_iter nor protobuf_iter support that message) and exposes them via a new BlobReader::header() -> &PbfHeader.
• replication_timestamp is required: BlobReader::open() now errors if the header block is missing or has no timestamp. In practice this never happens for the planet dumps we process. replication_sequence_number is intentionally not exposed — planet-dump-ng, the tool behind the actual planet.openstreetmap.org dumps, never sets it in the header.
• import_osm logs the parsed metadata at INFO level (structured, via log's key-value API) right after opening the planet file, so provenance is visible in pipeline.log ahead of a future change to embed it into our output files.

Why

We want to eventually stamp our output files with the provenance of the input planet data (replication timestamp etc.). This is the first step: get BlobReader to expose it and log it. Embedding it into output files is a follow-up.

Testing

• cargo test --lib pipeline::osm::tests and cargo test --test integration_test pass.
• cargo fmt --check and cargo clippy --lib -- -D warnings are clean.
• Manually verified the logged JSON line against the zugerland.osm.pbf test fixture (not the real planet dump):

  {"fields":{"replication_timestamp":"2026-01-27T08:11:02Z","source":null,"writing_program":"osmx"},"level":"INFO","message":"opened OpenStreetMap planet file", ...}

• Cross-checked the field parsing (tags, wire types, real values) against both the checked-in test fixture and the real planet dump in workdir/osm-planet.pbf by hand-decoding the header block with a throwaway script, to confirm osmosis_replication_sequence_number really is absent from real planet dumps and not just from the small test fixture.

🤖 Generated with Claude Code

[brawer]

LGTM