agent-core-v2: `[services.moonshot_fetch]` config is defined and documented but never read by the fetch path

What I observed

In the agent-core-v2 engine, web search honors the [services.moonshot_search] config section, but web fetch does not honor the sibling [services.moonshot_fetch] section, even though that section is defined in the schema and documented.

Search resolves its backend from config first, then falls back to the managed Kimi OAuth provider:

• packages/agent-core-v2/src/app/auth/webSearch/webSearchService.ts:50

  getWebSearchProvider(): WebSearchProvider | undefined {
    return this.fromServicesConfig() ?? this.fromManagedOAuth();
  }
  

  where fromServicesConfig() reads config.get(SERVICES_SECTION)?.moonshotSearch.

Fetch has no fromServicesConfig() equivalent — getUrlFetcher() only builds a provider from the managed OAuth provider, otherwise returns the local fetcher:

• packages/agent-core-v2/src/app/web/webService.ts:43 — reads the managed kimi-code provider only; the [services.moonshot_fetch] section is never consulted.

Meanwhile the section IS defined and serialized:

• packages/agent-core-v2/src/app/auth/configSection.ts:47 (moonshotFetch: MoonshotServiceConfigSchema.optional()) and :81 (writeService(out, 'moonshot_fetch', ...)),

and it is documented alongside moonshot_search with identical fields:

• docs/en/configuration/config-files.md (services section: "configures two built-in services: web search (moonshot_search) and web fetch (moonshot_fetch)").

The v1 core does read it (packages/agent-core/src/rpc/core-impl.ts, input.config.services?.moonshotFetch), so this looks like a v2 parity gap rather than an intentional removal.

Effect

A user who sets [services.moonshot_fetch] base_url = "…" (with api_key/oauth) expects FetchURL to route through that endpoint, exactly as [services.moonshot_search] already does for WebSearch. Under the v2 engine it is silently ignored and fetch falls back to the local fetcher.

Question before any PR

Per CONTRIBUTING (discuss first), is this considered a bug worth fixing, or is the v2 fetch-from-config path intentionally deferred while the engine is experimental? If a fix is welcome, the focused change would be to give WebFetchService.getUrlFetcher() a fromServicesConfig() path that builds a MoonshotFetchURLProvider from [services.moonshot_fetch] (base_url + apiKey/oauth), mirroring WebSearchProviderService.fromServicesConfig(), with config taking precedence over the managed derivation. Happy to open that PR with tests if you'd like.

Start with packages/agent-core-v2/src/app/web/webService.ts and compare its getUrlFetcher() with fromServicesConfig() in webSearchService.ts. Read configSection.ts and the v1 implementation in packages/agent-core/src/rpc/core-impl.ts, then add focused tests showing that moonshot_fetch configuration is honored and takes precedence over managed derivation.