feat(core): adopt the Trust-Task endpoint contract

[stormer78]

Adopts the contract settled in trust-tasks #251 (HTTPS binding 0.2) and
VTI #1020.

The contract

The HTTPS binding has always fixed the request path at /trust-tasks.
Nothing said what that path was relative to. So this plugin appended
/api/trust-tasks to its configured base while trust-tasks-https appended
/trust-tasks — and both were conformant, because there was no contract to
violate. Two implementations agreeing by convention is not a contract; it hides
the absence of one.

Binding 0.2 §6: the advertised serviceEndpoint is the Trust-Task base, and
the URL is <base> + "/trust-tasks".

The dispatcher path moves

RestChannel now defaults to /trust-tasks. The suffix lives in one
constant instead of being spelled at each site — the divergence this fixes
happened precisely because two implementations each wrote it themselves, so
anything composing a dispatcher URL goes through trustTaskUrl.

This makes vta-service 0.18.0 a hard floor

A VTA older than #1020 serves only /api/trust-tasks and will 404. There is
no fallback, deliberately, and the alternative was considered rather than
overlooked: this plugin was one of the clients keeping the superseded route's
usage metric above zero, and that metric is what governs retirement. A client
that never moves is a route that can never be retired.

Endpoint discovery (new)

vta/endpoint.ts turns a resolved DID document into a Trust-Task base, or
undefined when none is advertised — which is not an error: §6.3 keeps
out-of-band configuration conformant, and a configured base is the supported
path today.

Four behaviours are load-bearing rather than incidental:

behaviour	why
matched on service type, never the id fragment	the fragment is an arbitrary controller-chosen label; matching it makes interop depend on a convention nobody agreed — the same rule the Rust side applies to DIDCommMessaging/TSPTransport
a VTARest entry does not satisfy discovery	the whole reason the binding defines a dedicated type — "is a VTA's REST API" and "accepts Trust Tasks over HTTPS" are different claims that coincide only because every Trust-Task server we run happens to be a VTA
non-https: is rejected, not quietly used	REST is the only channel carrying a bearer; TLS in front of the receiver is why that is safe
a path prefix in the base is preserved	https://host/api means the dispatcher is at https://host/api/trust-tasks — that asymmetry is the ambiguity the contract removes

DID Core's alternative shapes (type as an array, serviceEndpoint as a map or
array) are accepted, because the DIDComm entries in this codebase already use
the map form — assuming the string form from the binding's examples would reject
valid documents.

Scope

Nothing calls discovery yet. The wallet still reaches its VTA by configured
URL, which remains conformant. This lands the capability and its tests so that
adopting it later is a call site rather than a design.

Worth knowing for whenever that happens: DID-based discovery here will still hit
HOST_PERMISSION_REQUIRED, because vta-service uses an origin allowlist rather
than the permissive CORS the webvh hosting service serves. That is the existing
just-in-time permission flow, not a new constraint.

No dependency changes. Every @openvtc package is already at its newest
published version (trust-tasks 0.12.1, vti-didcomm-js 0.6.2,
vti-tsp-js 0.2.0) — reported rather than churned.

Verification

npm test — 539 passing, 0 failing, including package.module-boundaries
and package.entry-points. Both matter here: endpoint.ts is a new module in a
layered package, and vta/ is a published entry point that must import in plain
Node with no DOM.

Nine new tests cover the table above plus trailing-slash handling, first-usable-
entry selection, and the single-definition-of-the-suffix invariant.