Add SEDI guardianship represented-presentation worked example

[dhh1128]

This PR adds a worked example of a a digital guardian presenting a fact about a ward (a person who cannot fully consent) to a verifier, under SEDI). It is part of a set of changes, and is an example whose holder is not the subject, a sibling to test_cp_disclosure.py and test_examples.py.

Scenario. Bob, a custodial parent, proves to an age-restricted online service that his 14-year-old ward Cara is over 13 — without disclosing her birthdate, which other age thresholds exist, or any ward attribute beyond the predicate — while the service can prove afterward that a guardian (not the child) acted.

Three edge operators are interesting in this scenario:

• I2I (authority): presentation → Bob's guardian credential — proves the presenter holds the authority.
• NI2I (ward data): presentation → Cara's identity/age credentials — Bob is not the subject; an I2I ward edge would be impersonation.
• E1E (identity): Cara's age → her identity credential — same subject, issuer != issuee — consuming the operator added in Add E1E identity edge operator to credential chain verification #1527 over its aggregate far-node path (.iseaid → A[1].i), end to end.

The code demonstrates: guardian-mediated aggregate predicate disclosure (unlinkable over-13, birthdate withheld), holder ≠ subject with a gated IPEX exchange, blindable-registry dynamic revocation, and a verifiable accountability chain back to an accountable human — things a document-centric mDL/EU-ARF flow cannot express.

The credential shapes are minimal ports of the draft sedi-guardian family in bakobo/schema. One divergence worth a decision: the draft uses ri for the registry field, while keri v2 (acdcmap/acdcagg) emits rd — this example uses rd (ground truth). Candidate revision to the bakobo first-cut schema.

Rebased onto main after #1527 merged; the diff is now the worked example alone.

[dhh1128]

Updated: rebased onto current main (now including #1529) and converted the IPEX request to the dp construct settled in discussion #1549 — matching #1561, which does the same for the two already-merged examples.

• disclose (attribute section, dict keyed by schema SAID) → dp in the query section (exchange(modifiers=...)), holding an ordered list of (schemaSAID, [paths]) pairs.
• Paths are ACDC-relative, so no leading / — under Revised Disclosure Paths `dp` field value syntax #1549 a leading / roots the path at the DAG origin, which would make /a/i name the origin's issuee rather than the credential the tuple names.
• The solicited offer now carries dp: [], meaning "the same paths the apply asked for".

The represented-presentation case is the one where the joining paths carry real weight: the service asks for the issuee from both the guardian credential (a/i, who is acting) and the ward's age credential (A/i, whose fact is asserted), and those two AIDs are deliberately different. It is the guardianship edge, not issuee equality, that licenses Bob to speak for Cara — so the request has to name both and the verifier has to check the edge rather than compare the two issuees.

Same open question as #1561, flagged in a comment at the call site: #1549 says the zeroth tuple MUST be the DAG origin, but a first-contact apply cannot name the bespoke presentation's schema SAID (#1512). Origin tuple omitted for now; @SmithSamuelM, this is the question still open on #1542.

Still a single commit adding a single file. tests/acdc/ is green (54 passed). The apply/offer SAIDs moved, and the agree/grant/admit SAIDs that chain off the offer via p moved with them.

[dhh1128]

Rebased onto the current branch head and updated to match #1561, which took two changes @SmithSamuelM settled after both PRs were opened.

The apply's dp list now carries the zeroth origin tuple. #1549 says the zeroth element MUST represent the DAG origin; I had omitted it here and on #1561 on the grounds that a first-contact applicant cannot name a presenter-issued origin's schema. #1542 answers that — the origin is presenter-issued but its shape is governance, so the applicant does know it. In a represented presentation the origin entry earns its place twice over: asking it for issuer and issuee is the first point at which the holder != subject split is visible, since the origin's issuer is Bob and the ward does not appear in it at all.

The _ DAG-hop component from #1549 changes no path data, since every path here is ACDC-relative and none crosses an edge. The comment now records the absolute rendering, which with three edges is the clearest of the three examples to read: /e/authority/_/a/i, /e/wardAge/_/A/over13.

The label-conformance guard that comes with the same discussion lands on #1561 rather than here, to keep it in one place. Both restrictions are proposed for the spec in trustoverip/kswg-acdc-specification#202, and dp itself in trustoverip/kswg-acdc-specification#203.

Five exn SAIDs moved through the p chain and were re-derived by running the example. All 8 tests pass on the rebased branch.