fix(ci-versioning): report both unverified reasons, always

[sakanni]

Why

Two warnings both opened with N failure(s) and neither said which axis it measured:

145 failure(s) attributed to this repo were not verified: BH.oM.Adapters.GSA...Fabric, ...
145 failure(s) could only be attributed to this repository by namespace, ...

The first is the unverified total; the second is the count whose ownership was inferred. Read together they say "all 145 were attribution problems, so resolution classified nothing" — i.e. that #18 was inert. The artefact for that run says otherwise:

ClassificationPath	count
UnresolvableTypeAbsent	114
NoMethodEvent	31

Correct numbers, wrong conclusion, entirely from presentation. No classification or attribution behaviour changes here.

What

1. New Unverified basis: line, printed unconditionally beside Attribution basis::

Attribution basis: 0 by declaring assembly, 98 by namespace fallback (no declaring assembly recorded)
Unverified basis: 66 unresolvable (a type the record needs is absent from the closure), 32 unattributable (ownership inferred from a namespace prefix)

Extracted as UnverifiedBasis so the arithmetic is testable. Unresolvable is counted by path; unattributable by subtraction from the unverified total, so the two always sum to it and a path added later cannot silently vanish — it lands in unattributable and shows up as a number nobody expected, rather than in neither.

2. The namespace-fallback warning no longer leads with a finding count. It is a statement about the attribution basis of findings that may have been classified for a different reason, and phrasing it as N failure(s) is what made it read as a classification total:

Attribution basis, not a finding count: 98 of 98 finding(s) named no declaring assembly, so ownership could only be inferred from a namespace prefix … Of those, 66 were separately unverifiable because the closure could not resolve a type they need and are reported under that cause; 32 rest on the inference alone. None of them gate.

3. The job summary's breakdown rows print even when zero, and both bases appear in the table. A silent zero cannot be told from a number nobody measured — the same trap the attribution-basis line already had, and the one #32's methodological note is about.

Verification

End to end against the local closure:

Classification:    unverified/UnresolvableTypeAbsent=66, unverified/NoMethodEvent=32
Unverified basis:  66 unresolvable ..., 32 unattributable ...
Status: Warning   Failures: 0   exit 0

Suite 135 passed. Verified by mutation: deriving unattributable by path instead of by subtraction fails UnverifiedBasis_AnUnknownUnverifiedPath_IsNotSilentlyDropped and nothing else.

Pester 12 passed, including a check that nothing branches between the total and its two components. That is asserted by contiguity rather than by the absence of any if, because #17 legitimately uses elseif ($unverified -gt 0) further down for the findings-table prose — the broader assertion failed on that and was tightened.

Refs BHoM/internal-tickets#31, BHoM/internal-tickets#32