feat(vta-service): mint the step-up approve-request as 0.2; inbound stays bilingual

[stormer78]

Summary

The deferred follow-up to #870: the minted step-up approve-request moves from auth/step-up/approve-request/0.1 to /0.2. Receivers migrated first — vta-mobile-core (#871) and the browser plugin (OpenVTC/vta-browser-plugin#103) accept both request minors, and the webvh control plane accepts both approve-response minors (part of the signed-request-legs push, affinidi/affinidi-webvh-service#147) — so this is the producer-side cutover.

0.1 → 0.2 shape delta (from the dtgwg specs)

The approve-request payload is otherwise identical between minors — same required members (subject, sessionId, challenge, reason), same optional hints (targetAcr, ttl, webauthn, ext), same ttl semantics. What changes:

• type URI minor bump /0.1 → /0.2
• payload.acceptableEvidence enum spelling: did-signed → didSigned (webauthn unchanged) — the only payload-value difference
• spec error codes go camelCase (subject_unknown → subjectUnknown, …) — informational; the request leg emits none
• ext $ref moves to the 0.2 framework schema (no wire effect)

(The approve-response side's 0.2 additionally renames evidence.kind did-signed → didSigned and adds the delegated-approver approverUnauthorized semantics — both already handled by #870's dual-accept handler.)

What this PR does

• mint_pending_step_up emits the /0.2 type URI + didSigned wire spelling. Signing is exactly as feat(vta-service): sign the step-up approve-request (spec: proof REQUIRED) #870 built it: eddsa-jcs-2022, assertionMethod, {vta_did}#key-0, proof last over the complete document including payload.ext — the Cierge authorizationContext carriage is unchanged and stays inside the signed surface (existing test kept and passing).
• The DIDComm push type for the delegated approve-request follows the document to /0.2.
• Inbound stays bilingual (approvers in the field answer with either minor during the transition):
  • the trust-task dispatcher keeps accepting approve-response 0.1 and 0.2 (typed dual-accept over the signed bytes — unchanged);
  • the DIDComm router's canonical step-up-approve registration now accepts the /0.2 request URI beside /0.1 and the legacy vta/step-up/*/1.0, echoing the caller's own minor in the response type (the control plane accepts both response minors).
• The stored PendingStepUp.acceptable_evidence keeps the internal kebab canonical form — it is state, not wire — so in-flight 0.13.17 pending step-ups stay consumable across the deploy.

Tests

• New integration round-trip (v0_2_minted_request_completes_with_a_0_1_flavored_response): the real gate mints the 0.2 request, its VTA proof verifies end-to-end via di_proof (issuer == proof VM DID), and a 0.1-flavored signed approve-response (kebab did-signed evidence) completes the 0.2-minted step-up, acking in the approver's 0.1 family.
• Existing 0.1/0.2 approve-response, delegated, unauthorized-approver, and ext-carriage tests all updated/passing.
• cargo test -p vta-service --no-fail-fast: all green. tests/e2e (embedded mediator): 162 passed, 11 ignored (need the webvh-host fixture). fmt + clippy clean.
• A genuinely cross-repo webvh↔plugin e2e is not feasible from this repo; the cross-version guarantees are covered by the integration round-trip here plus the receiver-side tests landed in feat(mobile): verify request proofs on-device before prompting #871 and feat: verify every approval leg against the enrolled-executor set vta-browser-plugin#103.

Release

vta-service 0.13.17 → 0.13.18, root CHANGELOG entry under Unreleased.

Refs #870, #871, affinidi/affinidi-webvh-service#147, OpenVTC/vta-browser-plugin#103.