chore(deps): move the workspace to the published head (trql-client 0.16, vta-sdk 0.35, TDK 0.13)

[stormer78]

What

Moves the workspace onto the published head of the stack. Two commits:

1. trql-client git rev → "0.16" — retires the pin now that the registry has published, and removes the last git dependency from the lockfile.
2. vta-sdk 0.34 → 0.35, affinidi-tdk 0.12 → 0.13 — the line VTI main runs and the registry merged onto in #133.

Plus cargo update for the transitive set. No source change was needed for either step.

Commit 1 — retire the git pin

trql-client was pinned to a git rev because the last published version (0.14.0) declared trust-tasks-rs ^0.9 against a stack on ^0.17. The registry has now published through 0.16.0. The rev → 0.16.0 diff touches only trql-client/src/client.rs, and only to route builder failures through one payload_build_error helper — none of the symbols verify-trust imports changed.

cargo publish rejects git dependencies outright, so publish.yml could not have got past the manifest on a release tag while the rev stood. That blocker is gone (see caveats for the one that remains).

Commit 2 — vta-sdk 0.35 / TDK 0.13

⚠️ This one leads the consumer instead of following it — knowingly, and the manifest now records it as a temporary, known break rather than a new licence to lead.

Workspace	vta-sdk	TDK	trust-tasks
VTI main	0.35	0.13	0.19.4
this PR	0.35	0.13	0.19.4 (+0.18.11, below)
OpenVTC main	0.34.1	0.12	0.18.5

OpenVTC is still a minor behind with no branch in flight. Until it moves, a build taking both did-git-sign and vta-sdk directly resolves 0.34.1 and 0.35.0 together — and vti-common re-exports vta_sdk::acl::{ActScope, ApproveScope, ContextDirection} as its own public API, so those copies carry types that cannot unify. OpenVTC needs a follow-up move to 0.35; that debt is the thing to clear next.

Known duplicate

trust-tasks-rs splits as a side effect — trql-client 0.16 declares ^0.18, vta-sdk 0.35 declares ^0.19.4:

trust-tasks-rs v0.18.11
└── trql-client v0.16.0
    └── verify-trust

with every other consumer on 0.19.4. This is the narrowed, historically tolerated shape: verify-trust passes no trust-tasks type across trql-client's HTTPS transport, and did-git-sign — the crate OpenVTC consumes — has no trql-client edge at all (cargo tree -p did-git-sign | grep -c trql → 0), so the duplicate never reaches a graph where a type has to unify.

trql-client 0.17.0 is the fix: merged upstream as registry d99228a (#133), declares ^0.19.4, collapses the tree to one copy. It is not taken here as a git rev — that would re-block cargo publish at the manifest, which commit 1 just cleared, to buy a duplicate that is already tolerable. Bump to "0.17" when it reaches crates.io; I verified the coupled move locally (single trust-tasks-rs 0.19.4, clippy and tests green, no source change).

Testing

cargo fmt --all --check, cargo check --workspace, cargo clippy --workspace --all-targets -- -D warnings, cargo test --workspace (136 pass), and cargo +1.95.0 check --workspace for MSRV — all clean.

Pre-existing, not fixed here

Both present on main:

• cargo audit reports RUSTSEC-2023-0071 (rsa 0.9.10 via pgp 0.20 and ssh-key 0.6). No upstream fix available; not a CI gate.
• cargo publish --dry-run -p verify-trust still fails: the published vgi-core 0.4.7 predates signer_did / conflicting_signer_dids while the packaged build resolves it from crates.io. vgi-core needs republishing before any dependent can go out.

Follow-ups

• Move OpenVTC to vta-sdk 0.35 / TDK 0.13 (clears the leading-the-consumer debt)
• Bump trql-client to "0.17" once published (collapses the trust-tasks duplicate)
• Republish vgi-core (unblocks releases)

[affinidi-appsecurity-bot]

🛡️ AI Agentic Security Code Review — all clear. We checked this change and found nothing to report. Keep shipping secure code!

Note: for major, breaking, or feature-introducing changes, you can always request an in-depth review from the security team.