Bug type

Regression (worked before, now fails)

Summary

Gemini native PDF analysis can fail with 404 because one runtime bundle still builds endpoint as .../v1beta/v1beta/models/... when baseUrl already includes /v1beta.

Steps to reproduce

1. Configure agents.defaults.pdfModel as google/gemini-3.1-pro-preview.
2. Call pdf tool with a local PDF.
3. Execute through path using dist/subagent-registry-*.js (e.g., sessions_spawn runtime=subagent).
4. Observe: Gemini PDF request failed (404 Not Found).

Expected behavior

pdf should call .../v1beta/models/{model}:generateContent (single version segment) and return output.

Actual behavior

In affected path, URL becomes .../v1beta/v1beta/models/{model}:generateContent and Gemini returns HTTP 404.

OpenClaw version

v2026.3.2

Operating system

macOS 25.3.0 (arm64)

Install method

npm global + local gateway

Logs, screenshots, and evidence

Evidence (v2026.3.2 local dist):
- Fixed logic in dist/reply-*, dist/plugin-sdk/reply-*, dist/pi-embedded-*.
- Bug remains in dist/subagent-registry-* with hardcoded /v1beta append after baseUrl.
- Local hotfix + restart makes native PDF succeed in both main and subagent paths.

Impact and severity

Affected: users invoking Google native PDF via subagent/session-orchestrated paths.
Severity: High for affected workflows (tool blocked).
Frequency: 100% in affected path.
Consequence: PDF tasks fail with 404 and require fallback.

Additional information

Suggested fix:
Unify geminiAnalyzePdf URL construction across bundles.
Pattern: normalize baseUrl, append /v1beta only when missing, then /models/{model}:generateContent.
Suggested regression test: with baseUrl ending /v1beta, generated URL must remain single-version (no /v1beta/v1beta).