feat(join): read a community's requirements from the endpoint it publishes

[stormer78]

Rebased onto main (now carrying #341, #342, #343); single commit.

The VTC-side companion, verifiable-trust-infrastructure#1563, has merged — a community can now turn public discovery off. This PR handles that case as an ordinary failure: the manifest fetch comes back Refused, and the flow falls through to the DIDComm question exactly as it does for a community that publishes no endpoint at all.

Fixes the "could not learn whether … vets the people who join" screen a first join lands on.

The finding

That screen was accurate about what OpenVTC did and wrong about what was
possible. OpenVTC only ever asked for a community's requirements over DIDComm,
which needs a mediator socket, a persona to ask as, and a loop that can hear the
answer. A first join has none of those — the State-A loop has no inbound arm by
design — so the one screen an applicant most needs filled in was blank exactly
when they had least context.

The same answer is already public over HTTPS. A VTC publishes a VTCRest
service in its DID document, and POST {endpoint}/v1/trust-tasks dispatches on
the document's type. Confirmed against a live community — no auth, no
signature, rate-limited and body-capped server side, reply signed by the VTC:

POST https://first.openvtc.net/v1/trust-tasks
{"id":"urn:uuid:…","type":".../vtc/join-requests/manifest/0.2",
 "recipient":"did:webvh:…first-vtc","payload":{}}
→ 200  vetted-member, minStatements 1, name.legal, requirementsDigest
       signed by did:webvh:…first-vtc#key-0

Nothing in OpenVTC read VTCRest at all.

What changed

openvtc-core/src/vetting/discover.rs reads the manifest there, and
enter_community asks there first, falling back to the DIDComm question. So the
requirements arrive in one round trip everywhere, and arrive at all on a first
join.

The request names nobody. No issuer — the service answers one that names
nobody, and that is the point rather than a convenience: the join page promises
"nothing about you has been sent to {community}", and stamping a persona DID on
a pre-application read would quietly make that false. Reading what a community
asks of applicants must not tell it who is considering applying
(vetting-process.md §6.1, informed non-application).

The endpoint is attacker-influenced, so it is dialled under the guards the
health probe already uses — HTTPS only, no redirects, no proxy, no userinfo, and
a DNS resolver that refuses a name pointing at a non-routable address.
vet_probe_url is shared (made pub(crate)) rather than copied, so there stays
one URL guard.

The answer is trusted only as far as its proof. A manifest is what an
applicant gathers evidence against: a forged one could ask for a passport scan
the real community never wanted, which is the same phishing surface an
unverified agent name is (CLAUDE.md's rule). So the reply's Data-Integrity proof
is verified via verify_trust_task_proof_with and the proven signer must be
the community asked. A claimed issuer is not enough, and neither is TLS to a
host the DID document happened to name.

DiscoverError keeps the failures apart as R6.4 requires — NoEndpoint,
Blocked, Unreachable, Refused, Unreadable, Unproven, WrongSigner —
because those have different next steps for the operator, and a single fixed
hint for all of them is what that rule forbids. Every outbound step is bounded
(R1.2).

The guidance, which is the other half

When neither route works the page still appears, and it now says what to do. It
used to state the problem and offer a key, leaving the question the operator
actually has — is joining now a dead end? — to be guessed at.

On a first join it now says joining anyway is the way forward rather than a last
resort, and why: the request is recorded and messaging comes up with it, so this
community can be asked straight afterwards, and if it does vet, the application
can be made then and the join taken up again from it (#343). Where asking
could work it says to ask again instead. The two cases no longer share one
sentence.

Testing

• cargo fmt --all, cargo clippy --all-targets --all-features — clean
• cargo test --all-features -- --include-ignored — all green
• RUSTDOCFLAGS="-D warnings" cargo doc --no-deps --all-features — clean

Unit tests cover the VTCRest lookup in all three shapes a DID document may
write (string type, array type, object endpoint), a community publishing none,
the URL guard refusing plaintext / userinfo / loopback / a non-http scheme, the
request carrying no issuer, a refusal being reported by its message rather
than its envelope, and every DiscoverError reading differently from the others.

Verified live against first.openvtc.net during development — endpoint
resolved from the DID document, manifest fetched, proof verified against the
did:webvh signer, vetted-member / minStatements: 1 returned. Those checks
are deliberately not committed: CI's coverage job runs --include-ignored,
so a live-internet test would fail whenever that development community changes.

One thing that turned up while testing and is worth knowing: the VTC refuses a
document whose recipient is not itself (422 document recipient does not identify this consumer). So an honest server cannot be made to answer for
another community — the WrongSigner check is the guard against a dishonest
endpoint, which is exactly the case the server-side check cannot cover.

Policy note

The join flow dials under ProbePolicy::PublicOnly. A development stack on
loopback is therefore not read over REST and falls back to the DIDComm question,
which is the safe default; the --allow-private-probes escape hatch exists only
on openvtc health today.