fix(persona): say when a face is worn one context up, not just "nothing"

[stormer78]

A membership whose persona wears a face configured elsewhere read wears: nothing, with nothing on screen to explain why another surface showed that same persona wearing "OSS Developer". The answer was true and useless — which, on the one pane whose job is to tell a holder what they present, is the failure mode to avoid.

Why it happens

The VTA keys a binding on an exact (context_id, persona_did) pair and walks no hierarchy:

• vta-persona/src/binding.rs → binding_summary → binding_record → storage::binding_key
• the materialised_claims a disclosure draws on go through that same exact lookup

OpenVTC addresses the membership's sub-context (openvtc/<vtc-slug>) for both its read and its write — which is where community-scoped disclosure happens. A face bound against the parent context (openvtc) is a different row, and is genuinely not what the community sees.

So "nothing" was the right answer to the question asked. What was missing is that the holder had no way to find out the question had two plausible readings and they were looking at the other one.

(Ruled out along the way: context-local bindings are not a second address. set_local_binding writes into the ordinary pb: keyspace — local_binding_key is dead code — precisely because a split address space had made local bindings report bound: false and disclose nothing.)

What it says now

A fourth reading, distinct from the three already kept apart:

wears: nothing here — OSS Developer is worn in openvtc,
which this community does not see

Both halves are load-bearing. Naming the face is what connects this row to what the holder saw elsewhere; "does not see" is what stops the row being read as reassurance. The claim is safe to make in those words because both VTA read paths are exact lookups — this is not an inference about what the agent might roll up.

The parent is derived with context_path::parse_sub_context_id, never by hand: a top context may itself be nested, so the split is on the last /, and an id with no / is not a sub-context and has no parent to ask about. Same discipline as the didwebvh-rs and agent-names rules.

Cost

One extra round-trip, and only when a sub-context comes back unbound. The bound case — the common one — costs nothing. Best-effort like every other binding read: a failure looking up the parent leaves a perfectly good wears: nothing alone rather than turning it into an error.

Ordering is preserved where it matters, and both are tested:

• unknown still outranks everything. Reporting what a parent wears while the context actually in question went unanswered would be a confident statement built on a failed read.
• a bound context reports what it wears, never the parent.

What this deliberately does not do

It does not decide which context a membership's face ought to be bound in. That is a VTA/product question — the sub-context is where community-scoped disclosure happens, which argues OpenVTC asks in the right place, but that is an argument rather than a decision. This PR makes the current answer legible either way; if the canonical answer turns out to be the parent, the read address changes and this hint becomes dead code rather than becoming wrong.

Gate

cargo fmt --all; cargo clippy --workspace --all-targets -- -D warnings; RUSTDOCFLAGS="-D warnings" cargo doc; cargo test --workspace.

[affinidi-appsecurity-bot]

🛡️ AI Agentic Security Code Review

🔎 A manual security review is recommended before merging. Please contact the Security team for specifics and remediation guidance.

ℹ️ Detailed findings are not published on public repositories; the Security team holds the complete report.