[geoffturk]

Into feat/optional-trust-registry. This picks up where the branch's design doc §6 left off: "it needs an authenticated online VTA edit or upstream offline transport support". This is the authenticated online edit.

Why the referral Job failed

The referral Job ran the offline vta did-mgmt dids edit on the VTA's PVC. That binary holds no mediator session, so the only transport it can initiate toward a DID host is REST (vta-service/src/webvh_cli.rs builds its deps with DIDCommBridge::signing_only and tsp: None; Outbound::initiable_for then yields [rest]). A Full Stack dids daemon is provisioned through the VTA with a mediator, and in that case the webvh-service setup picks did-host-didcomm, which advertises TSPTransport and DIDCommMessaging and no HTTPS endpoint (did-hosting-common/src/server/vta_setup.rs, build_webvh_provision_ask). Empty intersection, hence no transport in common … it advertises [tsp, didcomm] and this agent can initiate [rest]. The offline command had also already committed the new log entry locally before it tried to publish, so the stack it ran on now has a local head the host has never seen.

The running VTA does not have the problem: it holds the mediator session, publishes to the host over TSP or DIDComm, and re-publishes an unconfirmed local head before applying the next update. The upstream fix for the error message itself is OpenVTC/verifiable-trust-infrastructure#2275; it does not change what the offline command can reach.

What this adds

• internal/vta: the farm's first client for a VTA. A did:key minted for one call; login as two Trust Tasks on /trust-tasks (auth/challenge/0.1 unsigned, auth/authenticate/0.2 signed) for a bearer token; vta/webvh/dids/get/1.0 for the VTA's head of the log; vta/webvh/dids/update/1.0 with document and expectedVersionId. Every authenticated document carries the bearer token and the did:key's proof, because the VTA checks that signer, issuer and session subject are one DID. Refusals are typed (TaskError, with the VTA's details.reason, conflict among them). vta/webvh/servers/domains/0.1, a read-only task the VTA answers only by reaching the host, is the probe that waits out the window after a restart in which the VTA serves HTTPS before its mediator session is up; an update in that window would commit locally and then fail to publish, the same failure as the offline one.
• publishRegistryReferral (internal/setup/trust_registry_referral.go) replaces the Job in EnableTrustRegistry. It skips the grant and the edit when the published document already carries the referral. Otherwise: grant the key as an admin of the VTC's context for an hour with vta acl create --role admin --contexts <VtcName> --expires 1h, in the same stopped-VTA window pattern as the registry context grant; log in; wait for the host to be reachable; read the head; send the update. When the VTA's head carries the referral but the host does not (the state the failed Job left), it sends the document unchanged, which makes the VTA reconcile the host and append a version. The verify phase is unchanged and still reads the host. The key is never stored; the entry expires on its own.
• internal/trusttaskclient: the envelope, the eddsa-jcs-2022 proof and the reply checks that internal/didhosting carried, so both clients share one implementation. didhosting keeps its names as aliases; its tests are unchanged.
• docs/optional-trust-registry-design.md: step 6 and the paragraph on the offline edit describe this path, the downtime note counts the second VTA window, and the host-side change that would let offline publishes work (a TrustTaskHTTPS entry on the daemon's own DID, which the daemon's readiness check already logs) is named as a separate change.

What I could not do here

• Run it against a stack. EnableTrustRegistry has no end-to-end test on the branch (it uses ExecCapture and builds the resolver inline), and I have no staging farm. The new step sits behind the newVtaClient seam so one can be written. On dev-myvta-fs, the first run will take the "head carries it, host does not" path, since the failed Job already committed the referral at the VTA.
• Confirm the exact wait after restart. The probe makes that a measurement rather than a guess: the step logs nothing until the host answers, and times out at three minutes with the VTA's last refusal in the error.

Verification

gofmt -l clean, go vet ./... clean, and go test on internal/vta, internal/trusttaskclient, internal/didhosting and internal/setup, all in a golang:1.26 container. The vta tests run the client against a fake VTA that verifies each request's proof and bearer, answers with signed replies, refuses an update with conflict, refuses the first probes the way a VTA without a mediator session does, and rejects a reply from another DID.