metadata.json fields outside MetadataEnvelope are discarded at ingestion with no trace (SRCRPMs, product_composer, generated_at)

[plusky]

Found while building the real-SLFO fixture for #397, and verified against both
checked-in metadata fixtures.

Summary

MetadataEnvelope (crates/mtui-testreport/src/metadata_parsers.rs:104-152)
models a subset of the fields a real metadata.json carries. It has no
#[serde(deny_unknown_fields)], so everything it does not model is silently
discarded at ingestion — no log, no error, no record that the data was ever
there.

Unmodelled in the records we have:

field	where it occurs
SRCRPMs	both fixtures, line 2 — tests/fixtures/metadata/metadata.json, tests/fixtures/metadata/slfo_metadata.json
product_composer	slfo_metadata.json (SLFO only)
generated_at	slfo_metadata.json (SLFO only)
binaries	not in either fixture; present in current SLFO 1.2 records, keyed by product

(id is modelled as realid at :132-134, and gitea_pr / gitea_pr_api /
gitea_commit_hash at :136-143 — those are fine.)

Why SRCRPMs in particular

SRCRPMs is an osc-qam field mtui deliberately declines to serve. It sits in
UNAVAILABLE_FIELDS (crates/mtui-core/src/commands/updates.rs:474), documented
at :469-471 as an "osc-qam field the TeReGen queue listing does not carry (yet)
— named so the error can say 'known, but not available here'. Tracked in #415",
with docs/src/faq.md:253 saying the same. That is accurate for the queue
listing.

But it is not the whole picture: for an update whose report is loaded, the
per-RRID metadata.json carries SRCRPMs and mtui parses that file. The data is
present at ingestion and thrown away, so updates -F SRCRPMs reports it
unavailable for a loaded template whose metadata is sitting on disk with the
value in it.

Suggested direction

Two separable pieces:

1. Model the fields worth keeping on MetadataEnvelope and store them on
   TestReportBase. SRCRPMs is the one with a caller waiting; the others are
   cheap once the shape exists.
2. Decide whether unknown keys should stay silently ignored. deny_unknown_fields
   is wrong here — metadata gains fields over time and a hard failure would break
   loading on every new field — but a debug! naming unmodelled keys would have
   made this visible years earlier, and is consistent with the direction prepare reports success without installing anything, and export then claims installed packages are absent (SUSE:SLFO:1.1:418286) #396 took
   for unparsable package entries.

Piece 1 may close part of #415's -F gap for loaded templates without waiting on
the TeReGen queue API; worth deciding whether it belongs there or here.

Note

No behaviour is broken today — nothing consumes these fields. This is a
"data discarded without a trace" report, in the same family as #396 and #407.