hub: witnessed vouch event — make sponsor Satisfied reachable (follow-up to PR 706)

[dp-web4]

Follow-up from the PR 706 review. F0.2 landed the sponsor predicate with the correct semantics, but one input is hardcoded false because the hub has nothing to read it from.

Today: a named sponsor who is a real key-bound member evaluates as Undecidable(VouchNotAttested) → operator review. SponsorVerdict::Satisfied is unreachable, so requires_sponsor: true effectively means "every applicant goes to a human." Honest, but not the end state.

Why: identity existence is not evidence of an act. The sponsorship relation is a field the applicant types, and member ids are not secret (public identity file, presence roster, member-to-member knowledge). Crediting resolvability would grant a peer factor the named member never gave.

Work:

• A witnessed sponsoring act — a member signs a vouch bound to (applicant, society, and ideally the applicant's pubkey + a nonce so it is neither forgeable nor replayable to another applicant/society).
• Project it, and have resolve_sponsor_verdict read it into SponsorFacts::vouch_is_attested (the seam already exists; the law predicate already handles both arms and is tested — see sponsor_consent_tests::an_attested_vouch_satisfies).
• Revocation/expiry semantics for a vouch.
• e2e: an attested vouch auto-admits; a vouch for a DIFFERENT applicant does not transfer; a revoked vouch stops satisfying.

Design note: this is the natural place to reuse the 17A conferral pattern (quorum of witnesses with backing attestations recorded) rather than inventing a second vouching mechanism — worth checking whether sponsorship should simply BE a single-witness conferral.

[dp-web4]

Two measurements from #760 (tests only) that change this issue's scope. Both came out of Legion's F0.2 review on the citizenship mesh thread.

1 — the vouch event is necessary but not sufficient. This issue's "Today" paragraph says requires_sponsor: true effectively means "every applicant goes to a human", and implies landing the vouch event ends that. Measured against the norm the live hub actually publishes — ADMISSION-REQUIRES-SOVEREIGN, selector: r6.request.action == member_join_request, decision: escalate, matching on the action alone — tighten_with_sponsor maps all nine verdicts to Escalate, Satisfied included. So making Satisfied reachable changes no admission outcome; the only observable effect is the sponsor_note on the queued request. The Work list needs a fourth item: a norm that distinguishes a sponsored join from an unsponsored one (or a narrowing of the escalate-on-action norm). Otherwise the vouch event lands and nothing appears to happen.

2 — the "Today" behaviour is not universal; the most authoritative sponsors take a different, wrong exit. sponsor_is_resolved_member is members ∧ member_pubkeys. Genesis seeds the founding Sovereign into members with no pin, and CouncilMemberAdded pins into council_pubkeys, never member_pubkeys. So naming the Sovereign or a co-Sovereign as sponsor returns Refuted(NotResolved) — the definite-failure arm — one clause before Undecidable(VouchNotAttested), with an operator finding that reads "named sponsor <uuid> is not a key-bound member of this society". That is false about the identity signing every ledger entry, and on a hub whose one norm is ADMISSION-REQUIRES-SOVEREIGN the Sovereign is the most natural sponsor to name.

Same root as #759's C8/C9: member_pubkeys is one of three key sources the resolver merges at RestState::new, and this predicate consults one. The fix is a choice (widen to the keyed-member union vs. accept that Sovereign/council cannot sponsor) and probably belongs with the witness-roster/id-bridge work, so #760 characterizes it rather than changing it.

hub workspace green at 166 + 299 + 3.