Stop gating C2PA confidence on a trust anchor that never ships

High-confidence C2PA attribution required signingCredential.trusted, a status code
the reader emits only when a trust anchor list is loaded. None ships, so from 0.27.0
through 0.30.0 the branch was unreachable in production for every vendor: an intact,
cryptographically bound manifest scored the same medium as a fallback parse that
validated nothing, which collapsed the one distinction the official reader exists to
draw. A hand-built info dict stamping that code kept the branch green in the suite.

Confidence now follows the binding. Signer trust and certificate expiry stay visible
as their own dimensions and as caveats, because a trust list that was never
configured is a missing input, not a finding against the credential. Every committed
provenance fixture with a reader result and an intact binding now reaches high
confidence, and test_no_committed_fixture_reports_a_trusted_signer guards the
reachability itself rather than a synthesized status set.

Revocation joins binding and signature failures as disqualifying. It arrives only on
signer_validity, so a check reading the other two returned a confident AI verdict off
a credential the issuer had disowned, with an empty integrity_clashes -- quieter than
a hash mismatch on the same file. Expiry stays non-disqualifying: it does not imply
the signed bytes changed, and a signature genuinely made outside validity already
arrives as claimSignature.outsideValidity.

The rule now lives in one place. _validation_fields maps status codes to the four
dimensions and names the failures that moved one; c2pa_info_has_invalid_credential
maps dimensions to disqualified. The ingredient-reachability walk and the
user-visible reason both consume that path instead of re-classifying raw codes, so
adding this one rule no longer means editing three layers in lockstep.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/python-api.md

@@ -160,9 +160,26 @@ print(report.c2pa_validation)
 
 `c2pa_validation`, when present, reports `integrity`, `signature`,
 `signer_trust`, and `signer_validity` independently, plus the reader status
-codes. A valid hash and signature with an untrusted or expired signer is a
-medium-confidence signed claim. A hash or signature failure does not confirm the
-claimed platform or AI origin. Fallback parsing reports unknown validation
+codes. A valid hash and signature is a high-confidence signed claim; an
+unanchored or expired signer appears in `caveats` and in these fields, not as a
+lower confidence, because the reader ships no trust anchors to check against and
+`signer_trust` is therefore a missing input rather than a finding. A hash or
+signature failure, or a revoked signing credential, does not confirm the claimed
+platform or AI origin.
+
+A consumer must read `integrity_clashes`. When a credential fails validation,
+`is_ai_generated` becomes `None`, because a claim that cannot be tied to these
+bytes cannot establish origin -- the manifest may have been transplanted from a
+real AI image onto anything -- and the failure is reported in
+`integrity_clashes` instead. That is a different question from whether an AI
+watermark is physically present in the pixels, which is what
+`has_invisible_target` answers, and it stays fail-safe `True` on the same file.
+Reading only `is_ai_generated` turns a broken vendor manifest into silence.
+
+`c2pa_validation["state"]` is the reader's own aggregate and is carried for
+diagnostics only; no verdict is derived from it, because it collapses a
+transplanted manifest and a merely expired certificate into one `Invalid`, and
+its `Trusted` level depends on anchors no default installation has. Fallback parsing reports unknown validation
 dimensions, while a raw marker in an unsupported or malformed container can
 leave `c2pa_validation` as `None`.