build(deps): take vta-sdk 0.39, so OpenVTC can follow without a duplicate

[stormer78]

VTI published vta-sdk 0.39.0, a major: verify_trust_task_proof_with became
generic over the payload, and KeyType gained ML-DSA variants.

While this line declared ^0.38, OpenVTC could not move. It consumes
did-git-sign, so raising its own pin resolved two sdk copies — 0.38.2 for
this crate and 0.39.0 for itself. That is the state OpenVTC's manifest records
having escaped "for the first time since 0.35", after the obligation here had
blocked six consecutive minors (0.23, 0.25, 0.27, 0.31, 0.32, 0.34).

This line's own note named the job: "It is one row here today; it will be two
in OpenVTC until that move happens, and that is the thing to fix next." This is
that move.

It compiled unchanged

No source edit was needed. Neither breaking change in 0.39 touches this
workspace: nothing here calls verify_trust_task_proof_with, and nothing
matches on KeyType (OpenVTC did, and needed a catch-all arm). The pin was the
whole of it.

Verified rather than assumed: cargo tree -i vta-sdk resolves a single
0.39.0 node, and cargo tree -d shows no sdk row at all. fmt, clippy --workspace --all-targets -D warnings and the full test suite are green.

Why a duplicate is not merely untidy

While the last one lasted it cost a cargo tree -d row rather than a build
failure, for a narrow reason: OpenVTC uses did_git_sign::{config, init} only,
so no sdk type crosses that boundary. One new import turns it into a type error,
because vti-common re-exports vta_sdk::acl types that cannot unify across
copies. Keeping this line current is what keeps that trap closed.