Persist and surface decision evidence for rejected or removed community membership

[stormer78]

Surfaced by an external RAHP/DRARM assessment of the Cypress release
(sankarshanmukhopadhyay/rahp-toolkit#18, finding OVTC-RAHP-03). This issue
covers the client half only; the governance half (appeal, review,
restoration) belongs in VTC/VTI and is tracked separately.

Problem

When a VTC rejects a join request or removes an active member, the decision
evidence reaches us on the wire and we throw it away.

VTC returns a typed reject code plus a reason
(vtc-service/src/messaging.rs:974 in verifiable-trust-infrastructure). All
four inbound paths in openvtc-core/src/messaging.rs have that code and reason
in hand:

• :308 — status: "rejected" on a join-status reply
• :392 — VerdictEffect::Deny, which even logs code and reason
• :473 — FORBIDDEN problem-report (invitation not accepted)
• :564 — join-denial trust-task-error, which logs code and detail

Each one then calls record.reject(), and
CommunityRecord::reject() / remove() take no arguments
(openvtc-core/src/config/account.rs:441-454). They set a status and clear
acknowledged. Nothing else is persisted.

The net effect for the operator: a community flips to Rejected or Removed,
the actions-required badge lights up, they press a key to acknowledge it — and
the why exists only in a tracing line they will never see. There is no
record of who decided, on what basis, or when. Acknowledging an outcome you
cannot inspect is not meaningful acknowledgement.

Expired has the same shape but is client-generated, so it is less severe —
still worth carrying the timeout basis for consistency.

Proposed change

1. Give reject() and remove() a decision-evidence argument and persist it on
   CommunityRecord:
   • deciding authority (the VTC DID that sent the decision)
   • decision code (typed) and human-readable reason
   • decision timestamp (theirs if present, ours as received otherwise)
   • the inbound path it arrived on, so the evidence is reconstructable
2. Surface it wherever the terminal state is shown — the communities list detail
   view and the actions-required notice — not only in the acknowledge prompt.
3. Keep it stable across the config round-trip (serde) so history survives a
   restart; inactive records are already retained for re-join
   (docs/design/multi-community-support.md R-S-1), and the evidence should be
   retained with them.
4. Where no reason is supplied by the VTC, say so explicitly ("no reason given")
   rather than rendering an empty field — absence of a reason is itself
   information the operator should see.

Out of scope

Appeal/review endpoints, policy-version context, and correction/restoration
semantics after an overturned decision. Those need the governing layer to define
them first; this issue makes OpenVTC ready to surface them.

Acceptance

• A rejected join and a removal each persist and display authority, code, reason
  and timestamp.
• A decision arriving with no reason renders explicitly as such.
• Round-trip test: evidence survives save/load.
• No decision evidence is lost between the four inbound paths — a test per path.

[stormer78]

Scoped this against the current code and the current VTI stack. The client-side
diagnosis in the issue holds — all four paths still discard the evidence, and
reject()/remove() still take no arguments (openvtc-core/src/config/account.rs:468-481).
Two things change the shape of the work.

The wire carries less than the issue assumes

Evidence available per path, checked against vta-sdk 0.28.0:

Path	Available
messaging.rs:392 — VerdictEffect::Deny	code + reason (VerdictWith, join_requests.rs:224-255)
messaging.rs:473 — FORBIDDEN problem-report	code + free-text comment
messaging.rs:564 — join-denial trust-task-error	code + detail
messaging.rs:308 — status: "rejected" poll	nothing

JoinRequestStatusResponseBody (join_requests.rs:178-189) is only
{request_id, status, needs, presentation_definition}. The VTC projects the
verdict only for Deferred (vtc-service/src/routes/join_requests/status.rs:131-155),
so a polled rejection arrives as bare {requestId, status:"rejected"}. Filed
upstream as OpenVTC/verifiable-trust-infrastructure#1052.

So the "test per path" acceptance criterion resolves to three paths carrying
evidence and one that structurally cannot until #1052 lands — which is exactly
the case proposal 4 ("no reason given") was written for, so nothing is lost, but
it should be a deliberate assertion rather than an accident.

Also worth noting on the Deny arm specifically: unlike Refer/RequestMore
(messaging.rs:404-441), it calls neither confirm_request_id nor
mark_acknowledged, so it doesn't even stamp receipt_at. Worth fixing in the
same change.

The removal half is unreachable

CommunityRecord::remove() has no production caller — the only call site in
the repo is the unit test at account.rs:1362. That is not an oversight here:
the VTC has no member-removal notification at all. AppState::send_to_member
has exactly one caller, on the credential-delivery path; nothing on a removal
path emits anything. A removed member only observes their VMC revocation bit
flip. Filed upstream as OpenVTC/verifiable-trust-infrastructure#1053.

So "a rejected join and a removal each persist and display authority, code,
reason and timestamp" cannot be demonstrated end to end today. The API can take
the argument; the path to exercise it doesn't exist.

Two smaller corrections

• "Deciding authority" can only mean the sending DID. The decision document
  is unsigned (proof: None), issuer is echoed from the request's recipient
  field which the applicant set, and the admin DID is written to the VTC's
  audit log but never to any wire response. Worth stating in the field's doc
  comment so it isn't later mistaken for attestable evidence.
• No decision timestamp exists. The document's issuedAt is when the
  response was produced, which for an admin reject diverges arbitrarily from
  when the decision was made. Proposal 1's "theirs if present, ours as received
  otherwise" therefore always resolves to ours, for now.

Implementation note

CommunityRecord deserializes through #[serde(from = "CommunityRecordShadow")]
(account.rs:195). A new field has to be added in three places — the struct,
the shadow (account.rs:294-346), and the From impl (account.rs:348-394) —
or the shadow's #[serde(flatten)] extra silently swallows it. communities_panel.rs:150-200
is the expanded detail block and the natural home for a Reason: row; it
currently shows Request ID: only for Pending.

Suggested revision

Narrow acceptance to: three inbound paths persist and display evidence, the
fourth renders "no reason given" explicitly, round-trip test, and the remove()
signature is prepared but untestable end to end. Track the removal display and
the poll reason as blocked on #1053 and #1052 respectively.

[stormer78]

Server-side update: the join-status path listed here as :308 now carries the
evidence, so that quarter of this issue is unblocked.

OpenVTC/verifiable-trust-infrastructure#1058 (merged) fixed
OpenVTC/verifiable-trust-infrastructure#1052 — the poll used to project
needs/presentationDefinition for a deferred request and bare
{requestId, status} for a rejected one. A poll of a rejected request now
also returns:

field	meaning
code	stable refusal code — the policy's own code on an auto-deny, or "admin-reject" when a human decided
reason	the policy's reason, or the operator's words. Absent, not empty, when none was given
decidedAt	when the decision was taken — deliberately not the response document's issuedAt, which is when the poll was answered. For an admin reject the two diverge by however long the applicant takes to poll

All three are skip_serializing_if-able, so they are simply absent on a
non-rejected request.

Three notes that bear directly on the proposed change above:

• Deciding authority (item 1) is already on the wire without a new field:
  respond_with sets the response document's issuer to the VTC DID. Worth
  knowing it is echoed from the request's recipient, i.e. a value the
  applicant itself set, so it is not independently verifiable — see the
  unsigned-response note in
  No removal notice reaches a member the VTC removes verifiable-trust-infrastructure#1053. What is not exposed is which
  individual admin decided; that was left out on purpose, since naming the
  rejecting admin to a rejected applicant is a safety call rather than an
  oversight.

• Item 4 — "no reason given" rather than an empty field — is honoured on
  the producer side: an admin who supplies no reason yields code with
  reason omitted entirely, never "". Test:
  status_rejected_by_admin_without_a_reason_omits_the_field.

• The decision is recoverable, not one-shot. That was the actual bug: the
  correlated VerdictResponse was the only place a {code, reason} ever
  reached an applicant, so a dropped socket or an admin decision taken hours
  later lost it permanently. The poll is now a genuine recovery path, which
  means the client can re-fetch evidence it missed rather than having to
  capture it on first delivery.

Still outstanding on the VTC side, for the other paths this issue names:

• Removal has no outbound notice at all —
  No removal notice reaches a member the VTC removes verifiable-trust-infrastructure#1053. CommunityRecord::remove()
  still has nothing to trigger it.
• One caveat on the shape: these three members are not in the published
  vtc/join-requests/status/0.1 response schema, which is
  additionalProperties: false. That divergence is deliberate and predates
  this change (submit/0.1 already returns a verdict envelope the schema
  does not describe), and is now tracked at
  No conformance witness for VTC Trust Task responses, and two already diverge verifiable-trust-infrastructure#1059. If you generate types from
  the published schema, they will not accept these fields.