[Gap]: Explain existing Fetch workload configuration changes

Stacklok docs team / @reyortiz3 — here is a ready-to-adapt subsection for the separate Fetch documentation follow-up in https://github.com/stacklok/toolhive/issues/6475 . This addresses configuration-state confusion; it does not claim the customer's registry-related symptom remains an unresolved runtime defect.

Before changing an existing Fetch workload

First inspect the local state:

thv list --all
thv config get-registry

Do not paste registry URLs containing credentials into a public issue. A stopped workload can still reserve the name fetch. If fetch exists and you want its saved configuration, thv start fetch resumes that configuration; start/restart do not apply new run-only flags. If fetch is already running with the desired configuration, no recreation is needed.

If you need different run-only settings, first record the intended configuration and assess interruption/consumer impact. Removing and recreating the workload requires the operator's decision: thv rm fetch removes the existing workload, then a reviewed thv run command creates it with the new configuration. Do not copy a gateway-access flag merely to work around a registry or permission error.

If fetch is absent yet lookup fails, inspect whether the configured registry is the intended one before changing permissions or registry settings. Do not automatically unset a custom registry.

A useful docs check has four rows: stopped+same config => resume; running+same config => no replacement; existing+changed config => operator-approved recreate; absent+lookup failure => inspect registry first. These are proposed instructions, not a transcript from an executed CLI session. The current command source and Fetch guide were reviewed; no workload or registry was changed. AI-assisted documentation suggestion, reviewed before sharing.

Start with the current command source and the Fetch guide mentioned in the issue, then adapt the proposed subsection into the appropriate documentation location. Check that it covers the four configuration-state cases, the registry and credential warnings, and the distinction between resuming and recreating a workload. Done means the guidance is reviewed without claiming an executed CLI session.