[Backend][Frontend] Wire the provenance triple (provider/model/promptVersion) into the deep-review payload so #1963's honest footnote can render

[Chris0Jeky]

Follow-up to PR #1985 (#1963). The frontend now renders provenance copy driven by the recorded triple and fails closed to silence — but no production caller supplies it.

Gap: ReviewMain.vue never passes metadata to ReviewProvenance, because no endpoint exposes the proposal's provenance provider/model — GET /automation/proposals/{id}/provenance returns row DTOs only, and the deep-review payload omits ProposalProvenance.ModelId/provider. So the footnote currently renders nothing (correct per #1963 — no claim beats a false claim), and the truthful 'processed by ' sentence is dead code until the payload carries the triple.

AC:

• The deep-review/provenance payload carries provider, model, promptVersion (server-recorded values only).
• ReviewMain passes them through; the fix(frontend): #1963 provenance copy driven by actual provenance #1985 branches render for real data (deterministic and live-provider cases both observed in a test).
• No client-supplied provenance accepted (existing invariant).

Refs: #1963, PR #1985, CaptureContracts.cs:18, ProvenanceDrawer.spec.ts:126.

[Chris0Jeky]

Scope correction from the PR #1985 review: no API surface returns provider/model to the SPA today — CaptureProvenance carries only captureItemId/triageRunId/proposalId/promptVersion, and ProvenanceDrawer's ProvenanceMetadata additionally expects confidence/latencyMs that nothing produces. So this is 'new API fields + mapping', not 'pass an existing prop'. ALSO: an honest EGRESS claim (the branch #1985 deliberately cannot make) needs a providerDispatched flag propagated into capture provenance — the discriminating signal already exists as LlmDispatchPhase.Dispatched (ILlmProvider.cs:133-143), the same one quota billing keys on. With it, a fourth truthful branch becomes possible: 'a provider was called; its output was discarded and the deterministic extractor produced this proposal.'

[Chris0Jeky]

Realignment 2026-08-23 — confirmed live on main a43df082c, and this issue is now more load-bearing than when it was filed: it also explains #1967's finding (c).

The gap is exactly as filed

frontend/taskdeck-web/src/views/paper/review/ReviewMain.vue:176-181:

<ReviewProvenance
  :rows="provenance"
  :evidence-links="evidenceLinks"
  :proposal-id="proposalId"
  @report="emit('report', $event)"
/>

No :metadata. Two consequences, both verified in source:

1. ReviewProvenance.vue:33-39 — footnote calls classifyProvenanceActor(props.metadata) and returns null when the actor is unknown. With no metadata the actor is always unknown, so the honest sentence PR fix(frontend): #1963 provenance copy driven by actual provenance #1985 shipped is dead code. That is correct behaviour per [Frontend][Trust] Review provenance footnote claims a "deterministic offline extractor" while captures are triaged by a live LLM provider #1963 (no claim beats a false claim), but the footnote cannot render until the payload carries the triple.
2. ReviewProvenance.vue:88 passes :metadata="metadata ?? null" straight through to ProvenanceDrawer, so ProvenanceDrawer.vue:264's <div v-if="metadata" class="prov-drawer__meta"> block — and the promptVersion row at :287 — never render either.

New: consequence 2 retires a finding on another issue

The 2026-08-22 horizon-journey run recorded View full read-set → as an inert dead link (#1967 finding (c)). It is not. ReviewProvenance.vue:84 binds @click.prevent="drawerOpen = true" and opens the drawer; the drawer is <Teleport to="body"> (ProvenanceDrawer.vue:233), so it renders outside the review pane and is invisible to a pane-scoped DOM diff.

The link works. The drawer it opens has an empty metadata block — for this issue's reason. #1967's finding (c) has been struck there and folded here.

That raises this issue's value materially: it is not only #1963's honest footnote, it is the entire provenance drawer having nothing to show. The auditable-decision-trail pitch depends on it.

Scope note still standing

The maintainer's own scope-correction comment — new API fields plus mapping, and a providerDispatched flag derived from LlmDispatchPhase.Dispatched for an honest egress claim — is not yet reflected in the AC list above. Worth folding into the ACs before implementation is scoped.

Sequencing

Priority II, so outside the v0.1.2 tranche — but it unblocks part of #1967, which is Priority I on v0.1.2. Worth the maintainer's attention when ordering that milestone.