transparency: analyze() threads its accumulators through 4-to-6-element tuples

[hherb]

Split out of the review of #35.

TransparencyAnalyzer.analyze() carries eight accumulators — score, indicators, industry_funding, industry_confidence, coi_disclosed, data_level, full_text_analyzed, funder_info_scored — by passing each into a sub-step and unpacking a tuple back out:

Sub-step	Returns
_check_crossref	5-tuple
_check_europepmc	6-tuple
_merge_pubmed_signals	6-tuple
_check_trial_registration	4-tuple

Each is individually readable, but the call sites are now multi-line destructuring assignments where the order of the elements is the only thing binding a value to its name, and #35 had to widen two of them to add one boolean.

Two real hazards, both currently latent:

• A mis-ordered unpacking is a silent type-compatible swap (industry_funding: bool and funder_info_scored: bool, score: int and any other int).
• funder_info_scored exists purely to stop SCORE_FUNDER_INFO being awarded twice. It was originally computed fresh inside _check_crossref, which is correct only while CrossRef is the first funder source consulted; transparency: query PubMed, and say why a result is UNKNOWN #35 threaded it in as a parameter to fix that, but the same shape invites the same bug for the next shared component.

Suggested shape: a mutable _Analysis dataclass holding the accumulators, passed to each sub-step and mutated in place, with analyze() reading fields off it at the end. Sub-steps return nothing (or just their own local finding). This removes the tuple arity entirely and makes "has this component been scored?" a named field rather than a positional bool.

Not urgent — nothing is broken today. Worth doing before the next signal source is added to analyze().