Add four-state validation model including offline/network-blocked state

[mrappard]

Summary

• Replaced the single-paragraph validation states component with a full four-state model — Trusted, Well-formed, Validation incomplete, and Revoked — each with a recommended user-facing label, required visual treatment, and plain-language description of what the state communicates.
• Added the new Validation incomplete state to cover credentials that require outbound network access (for example, to resolve a DID document or check revocation status) when that access was unavailable or blocked by the validator's policy. This corresponds to the cawg.identity.network_traffic_blocked status code in the CAWG identity assertion specification.
• Updated verification indicators to map all four states to specific icon types and added a four-row reference label table.
• Clarified that neither Well-formed nor Validation incomplete should be displayed as a warning state — both reflect limitations of the verification environment, not problems with the credential or the named actor.

Motivation

The previous guidance described validation as a failure/success binary with no handling for the case where validation simply could not be completed. This gap is significant because some credential types — particularly those using DID-based issuers or bitstring revocation lists — require network calls to validate fully. In environments where outbound traffic is restricted (air-gapped systems, enterprise proxies, offline viewers), an otherwise legitimate credential would have no appropriate state to fall into. Displaying it as "invalid" or using a warning indicator would misrepresent the situation and cast unwarranted doubt on the named actor.

The four-state model also lays the foundation for the three-state model introduced in prior issues (Trusted, Well-formed, Revoked) by formalizing all outcomes in one place.

Review notes - Validation incomplete shares the same neutral informational indicator as Well-formed. Ris the right visual treatment, or whether a distinct icon (for example, a clock or network symbol) would better communicate the specific reason validation could not be completed.

• The secondary explanation copy ("This credential requires an external check that could ronment") may need localization review.
• The Trusted NOTE on verifier-relative trust is repeated here from prior discussion — reongs in validation states or whether it is better placed in the principles section.

[grinstead]

I would add something along the lines here of "An unrecognized issuer has no proven standards, and so could present itself with whatever name it wants such as US Government. Therefore, the display should be hesitant to show any fields from the issuer without a sufficient warning."