Integrate Gateway's Google grounding redirect policy and actionable source-read recovery #374

Problem and outcome

Google grounding search returns provider redirect URLs. Desk's current reader reports web-redirect-origin as a generic cross-website failure. Gateway v0.11.0 closes Judgment-Pack/judgment-pack-gateway#230 with an explicit google-grounding policy, capability reporting and optional structured refusal details. Installing the release alone leaves the policy disabled.

Let an authorized operator review the policy, understand whether it is supported/enabled, and configure it through the supported installation path. Main chat, right-pane chat and future ICP research should share truthful, compact recovery UI.

Released contract

• gateway-connections --source-capabilities reports supported and enabled policies.
• A managed local plan accepts JPACK_WEB_REDIRECT_POLICIES=google-grounding in the companion environment, carried to adapter-web --redirect-policies=google-grounding.
• A refused source read can retain the fixed web-redirect-origin code and optionally include redirect: {from, to, policy, permitted: false}. These are origins only. Metadata may be absent because the relayed error line is bounded; hard refusals must not reveal private destinations.
• A successful permitted hop retains requestedURL, final URL and provenance.source.redirectPolicy.
• This permits one narrowly defined Google grounding-to-public-publisher hop. It is not general CORS configuration or arbitrary cross-origin access; requests and AI prompts cannot grant the policy.

Scope

• Read the released capability contract through Desk's server boundary. Preserve unknown/unavailable state for older or external Gateway installations; do not guess support from model/provider names.
• Add or reuse a shared Admin/Connections surface for policy status and explicit operator configuration. For a Desk-managed local Gateway, validate and apply the supported setting using the existing managed restart flow. For externally managed Gateway, give the operator the appropriate setup instructions instead of claiming Desk changed it.
• Preserve the default disabled state. Opening status/settings or encountering a blocked read must not enable policy or restart services; coordinate with existing lifecycle issues Document processing: status, configure and test can start the local gateway through ensure() before any decision is shown #356 and Document processing: two concurrent saves can both pass the restart check and restart the local gateway twice #357.
• Carry optional typed refusal metadata through document/link acquisition, saved work steps and chat tool results. Handle the legacy token-only response safely.
• Offer a contextual "Review web access settings" action only where the capability/refusal identifies an available policy. Explain hard-blocked destinations without suggesting a bypass.
• Allow AI to explain a reported setup requirement and point to the same UI. It cannot change the policy, silently switch providers or automatically replay acquisition after settings change.
• Use shared warning/status components and hyperlink styling. Explain the named publisher access and retain source/provenance details without exposing credentials or full opaque redirect tokens in warnings.
• Reuse this acquisition/recovery path in Add first-party ICP discovery using existing AI connections and evidence-backed candidate preparation #369; do not create a second ICP-specific web reader.

Acceptance criteria

• Policy disabled: a grounding result reports an actionable policy block when metadata supports it, and the publisher is not contacted.
• Explicitly enabled: a valid grounding result is read, with requested/final URLs and the applied policy retained through reload and evidence inspection.
• Unsupported/unknown capability, token-only refusal and externally managed settings each have accurate UI.
• Ordinary cross-origin redirects, private addresses, lookalike hosts and further cross-origin hops remain refused by Gateway; Desk does not bypass those decisions.
• Changing the setting requires an authorized operator action; chat content and source content cannot activate it.
• Main chat and pack/graph right-pane chat present the same compact recovery action, keyboard access and status.
• A read can be explicitly retried after configuration without silently replacing old failed work or changing qualification results.
• Focused contract tests and one configured live search-to-publisher check record their results and limitations.

Depends on the new Gateway bundle baseline. This is a prerequisite for the Google grounding route in #369, not for fixture-based development or other supported search routes.

Reference: Gateway v0.11.0, released web-source contract.

Dependency

Release baseline: #373.