chore(deps): take the vta-sdk 0.34 line the VTA and VTC deploy

[stormer78]

Refreshes the dependency graph onto what verifiable-trust-infrastructure main actually builds against, rather than onto what is newest on crates.io.

crate	from	to	why
vta-sdk	0.32.4	0.34.0	the line vta-service 0.24 is built on and VTI main deploys
trust-tasks-rs / -capability-client	0.17	0.18.5	vta-sdk 0.34 declares ^0.18.3; 0.18.5 is VTI's pin
affinidi-tdk	0.10	0.12	declared by vta-sdk 0.34, vta-service 0.24 and test-mediator 0.5
affinidi-messaging-sdk	0.21	0.22	the line built on trust-tasks 0.18
dtg-credentials	0.5	0.6	VTI is on 0.6, so the two agree again
vta-service (dev)	0.23	0.24	MockVta — the harness has to be paired with the sdk it tests
affinidi-messaging-test-mediator (dev)	0.4	0.5.2	0.4 pins sdk ^0.21 / TDK ^0.11 / trust-tasks ^0.17

These are not independent choices. TrustTask crosses the vta-sdk boundary in both directions, vti-common re-exports vta_sdk::acl as its own public API, and the messaging stack carries trust-tasks types in its API — so a crate left a line behind is a second, semver-incompatible copy whose types do not unify. The graph now holds exactly one vta-sdk, one trust-tasks-rs, one affinidi-tdk and one affinidi-messaging-sdk across normal,build,dev.

The one source change

vta-sdk 0.34 gave persona_attribute_list an include_sensitive argument, and pool::list passes include_values through to it. That preserves this client's behaviour exactly, and it is deliberate rather than expedient: the identity pane has one escalation (show_values) and this control needs two. show_values both asks the agent for values and reveals masked ones whole, so passing false would not narrow the read — it would make every sensitivity: high attribute come back valueless and render as (no value) under a reveal, which is a wrong answer about what the holder holds and one glance from "nothing is stored". masked_is_not_the_same_state_as_absent is the test that names that hazard.

What this does close is a documentation defect. claim_types's module header stated as fact that the sensitivity half of the registry "does not exist" because the task took include_values and nothing finer. It exists now; the header says so, and says what a client needs before it can use it — the s reveal fetching that one value on its own.

Deliberate holds

• dirs stays at 6 against a published 7. vta-sdk and did-git-sign both declare ^6 and this is the only line that could split them; 7's sole breaking change is preference_dir on Windows, and we call home_dir and config_dir.
• rand 0.8 and x25519-dalek 2 stay where their existing notes put them: pgp 0.20 is still the latest release and still declares both.

did-git-sign, for the sixth cycle running

The published 0.4.6 requires vta-sdk ^0.27, which against 0.34 does not merely split the graph — it fails to build. VGI cannot cut 0.4.7 while its trql-client git pin stands, so the [patch.crates-io] rev moves to the head of OpenVTC/verifiable-git-infrastructure#37 (VGI onto vta-sdk 0.34 / TDK 0.12, no source change, green on its own pipeline). The three-deep unwind back to a published 0.4.7 is unchanged and now written out in the patch block.

cargo-deny

Adds RUSTSEC-2026-0173 (proc-macro-error2 unmaintained) — a build-time proc-macro reaching only the dev graph, via vta-service 0.24's new vti-rooms -> openmls -> hpke-rs -> libcrux -> hax-lib chain. Removes RUSTSEC-2025-0134, which no longer matches anything and which cargo-deny warns about for that reason.

Gate

cargo fmt --all; cargo clippy --workspace --all-targets -- -D warnings; RUSTDOCFLAGS="-D warnings" cargo doc; cargo deny check (all four sections); cargo test --workspace; and cargo test --workspace -- --include-ignored so the MockVta e2es actually run against vta-service 0.24. Default and --no-default-features both check.

Merge order: OpenVTC/verifiable-git-infrastructure#37 does not need to merge first — the patch pins its head by rev — but it should merge, or this pin points at a branch that could be deleted.

[stormer78]

VGI#37 has merged, so the merge-order note at the bottom of the description is settled: the [patch.crates-io] rev now names VGI main at that merge (5111dc1, tree-identical to the branch commit it replaces) rather than a branch head that could be deleted under us.

Re-verified on the new rev: cargo check --workspace --all-targets, one vta-sdk / one trust-tasks-rs across normal,build,dev, cargo deny check all four sections, and the full suite including --include-ignored.

The merge discharges only the first obligation — VGI main builds on vta-sdk 0.34. It does not unblock the publish, because cargo publish rejects git dependencies and VGI still pins trql-client at the trust-registry PR head. So this PR keeps the patch block, and all three unwind steps stay open:

1. feat: move to trust-tasks 0.17, TDK 0.10 and vta-sdk 0.31 affinidi/affinidi-trust-registry-rs#128 merges and publishes trql-client 0.15
2. VGI swaps its pin back to "0.15" and tags → publish.yml cuts 0.4.7
3. OpenVTC deletes the patch block and floors did-git-sign at "0.4.7"