fix: route search_web to the Step Plan MCP endpoint

[AuroraAeon]

Problem

search_web resolves its MCP endpoint by login profile, but every profile — including step_plan and profile-less credentials — pointed at the balance-billed /v1/mcp/web_search/mcp path. Step Plan credentials are billed against the monthly Step Plan credit pool, so that path rejects them:

MCP tool stepsearch.web_search failed: Streamable HTTP error: Error POSTing to endpoint:
{"error":{"message":"You exceeded your current quota, please check your plan and billing details","type":"quota_exceeded"}}

The tool fails on every call, while chat completions with the same key keep working (session logs show cost: 0, i.e. Step Plan credit billing).

Reproduced live with one Step Plan key, same region:

Request	Result
POST https://api.stepfun.com/step_plan/v1/mcp/web_search/mcp — initialize + tools/call web_search	200, real results
POST https://api.stepfun.com/v1/mcp/web_search/mcp (current default)	402 quota_exceeded
POST https://api.stepfun.com/v1/search (REST, for reference)	402 quota_exceeded
GET https://api.stepfun.com/v1/models and .../step_plan/v1/models	200 — the key itself is valid

The StepSearch MCP documentation prescribes the /step_plan/... URL for MCP clients: https://platform.stepfun.com/docs/zh/step-plan/integrations/search-mcp

Credentials without a profile field hit this too: ModelRuntime.setRuntimeApiKey persists --api-key / STEP_API_KEY credentials as { type: "api_key", key } with no profile, so readStepLoginProfile() returns undefined and the tool fell back to the /v1 endpoint.

Changes

• Add SEARCH_WEB_MAINLAND_STEP_PLAN_URL / SEARCH_WEB_OVERSEA_STEP_PLAN_URL.
• Route step_plan and step_plan_oversea to the documented Step Plan MCP endpoints (credit-billed).
• Route unrecognized/profile-less credentials to the mainland Step Plan endpoint instead of /v1.
• platform_cn / platform_oversea keep the existing balance-billed /v1 endpoints — unchanged, since that path is what those profiles already used.
• Update docs/step-integration.md to match, and drop the duplicated env-var names in that paragraph (STEPCODE_SEARCH_API_KEY and STEPCODE_SEARCH_WEB_MCP_URL were each listed twice).
• Tests: per-profile endpoint expectations in resolveSearchWebServerUrl, a split expectation for the two overseas profiles, and a regression test for profile-less credentials (the reported failure mode).

Verification

• npm run check — passes (exit 0).
• Targeted vitest packages/coding-agent/test/step-search-web.test.ts — 9/9 pass.
• ./test.sh — test:scripts (34 tests) passes.
• Full recursive run (pnpm -r --if-present test --no-bail) on Windows fails on 29 test files, all Windows-only issues (path separators / vs \, EACCES vs EPERM, ESM c: URL scheme, missing SIGCONT, …). I reran the identical command with all changes stashed on a clean upstream/main: the failing-file set is identical (29 = 29, zero diff), i.e. this PR introduces no regressions.
• Live smoke test: with STEPCODE_SEARCH_WEB_MCP_URL pointed at the Step Plan endpoint, tools/call web_search returns real search results end to end.

Notes

• STEPCODE_SEARCH_WEB_MCP_URL still accepts a full URL to override any of this. If it is set to a bare origin, the code appends SEARCH_WEB_MCP_PATH (/v1/mcp/web_search/mcp); making that profile-aware would be a separate follow-up.
• Unrelated Windows issue, not touched here: scripts/build-coding-agent-bundle.mjs calls execFileSync("npm", ...), which fails with ENOENT/EINVAL on Windows under Node 25, so ./test.sh cannot build from a fresh checkout there. Happy to open a separate PR for it.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.