Add guidance for actors with multiple trust registries

[mrappard]

Summary

• Adds a new "Multiple trust registries" subsection to individual-and-organizational-identity.adoc, addressing organizational named actors whose credentials are recognized by more than one trust registry.
• Specifies that verifiers should respect the actor-specified order of trust registries as a display-priority signal: the actor's first-listed registry is shown as the primary trust indicator by default, with other recognized registries available via progressive disclosure rather than hidden.
• States implementers must not silently reorder or override the actor's specified priority, since doing so could misrepresent which trust relationship the actor intended to emphasize.

Why
Currently the guidance only describes verifier-configured trust lists (line 27) without addressing the case where an actor's credentials span multiple registries. This leaves an open question for implementers about which registry to surface as primary and risks inconsistent or verifier-biased presentation of trust.

Scope
Organizational identity only — individual identity doesn't currently reference trust registries.

🤖 Generated with Claude Code (https://claude.com/claude-code)

[RobertsRobots]

Strong +1 on the core principle: the creator sets the order, the verifier respects it, no silent reorder. As an implementer running both a C2PA verifier and a creator registry, two cases I'd want the guidance to pin down, since they're where "respect the order" gets ambiguous:

Unrecognized registries in the list. A creator lists [RegistryA, RegistryB], but a given verifier doesn't recognize RegistryA. The tempting shortcut is to promote the first recognized registry into the primary slot, but that quietly turns the rule into "respect the order among the ones I trust," which can misrepresent what the creator meant to emphasize. I'd suggest preserving the creator's order and rendering an unrecognized first entry in a distinct "not recognized by this verifier" state, rather than filling the primary slot with a lower-priority one.

Consistency across the stripped-manifest path. The common real case is a platform stripping the manifest, after which a verifier falls back to a registry or DID lookup to re-associate the creator. For the order to stay consistent, it has to live somewhere the re-lookup can read it (the registry record or credential), not only the embedded manifest. Otherwise the embedded and looked-up paths diverge and you get back exactly the inconsistency this PR is preventing. Worth a sentence saying the order should travel wherever the identity is re-resolved.

Minor wording: where the primary registry is surfaced, have the UI name it explicitly rather than collapse it to a generic "Verified," or the creator's chosen emphasis never reaches the viewer.