Move the google-vertex static model catalog from the TypeScript runtime
catalog (provider-catalog.ts / provider-discovery.ts) to the manifest
JSON (openclaw.plugin.json) with discovery: "static".

The model picker's "Browse all models" reads from manifest JSON via
planManifestModelCatalogRows, not from the staticCatalog.run callback.
The runtime catalog approach only served the "openclaw models list" CLI
command, leaving the model picker empty. Moving to manifest JSON serves
both paths.

Models: gemini-flash-latest (default), gemini-pro-latest,
gemini-flash-lite-latest, gemini-3.1-pro-preview, gemini-3-flash-preview.

Remove buildGoogleVertexStaticCatalogProvider() and revert
provider-discovery.ts to only return google (AI Studio) models. No
duplication, single source of truth in the manifest.

Add models.providers["google-vertex"].models to the auth flow's
configPatch so the default model (gemini-flash-latest) is registered
in the provider config when the config is written to disk.

The applyPrimaryModel path correctly sets models.providers in memory
but the value is lost during the wizard's config serialization. The
configPatch path persists reliably (proven by env values persisting
through the same mechanism).

Return a gcp-vertex-credentials marker profile from the google-vertex
auth flow instead of empty profiles. This makes the auth detection
system recognize google-vertex as having valid auth, which fixes:

1. The "No auth configured" warning during onboarding model check
2. The model picker auth filter dropping all google-vertex catalog
   models (only the configured model was visible)

Add nonSecretAuthMarkers: ["gcp-vertex-credentials"] to the google
plugin manifest so the auth system treats the marker as a non-secret
auth token. This matches the anthropic-vertex plugin which uses the
same marker for the same purpose (ADC-based auth with no real API key).

The transport layer recognizes the marker via
isGoogleVertexCredentialsMarker() and resolves a real Bearer token
via google-auth-library at request time.

Add an explicit providerAuthChoices entry for google-vertex to override
the auto-generated label. The auto-generation derives the label from the
provider id ("google-vertex" → "Google Vertex") which drops the "AI"
suffix. The explicit entry sets groupLabel to "Google Vertex AI" to
match the full product name.

…ss-references

Update the google-vertex docs page:
- Add models.providers section to the config example to match what
  onboarding actually writes
- Add Verify step to the service account tab
- Clarify that GOOGLE_CLOUD_PROJECT is auto-detected during onboarding
  on GCE/GKE
- Note that gemini-flash-latest is the default model set by onboarding
- Clarify that the OpenAI routing issue only affects custom configs

Add cross-references between google.md and google-vertex.md:
- Add a Note on the google.md page pointing users to google-vertex
  for GCP project billing and credits
- Add a Related card on google.md linking to google-vertex.md

…g entry

The transport type defaults to google-vertex automatically (commit
7ba19c8). No user going through the normal onboarding flow would
encounter this issue.

…ormatting

- Change GOOGLE_APPLICATION_CREDENTIALS default from "Auto-detected" to
  "None" since the env var is not auto-detected (the system falls back
  to the default gcloud ADC file path, but that is a file lookup, not
  env var detection)
- Add guidance to the "No API key found" troubleshooting entry noting
  this should not appear after onboarding and suggesting re-running
  onboarding if it does
- Remove stray blank line before closing AccordionGroup tag

Add providers/google-vertex to the Mintlify docs.json navigation config
so the page appears in the sidebar between Google (Gemini) and Gradium.

- Remove AI Studio comparison from intro paragraph and credits note.
  The page should describe what google-vertex is, not compare it to
  another provider.
- Rename "Local development" tab to "gcloud CLI" to match the
  credential type naming pattern used by other tabs. No other provider
  docs page uses "Local development" as a tab title.
- Fix Related card title from "Google (AI Studio)" to "Google (Gemini)"
  to match the actual page title of google.md.

- Update frontmatter summary to use "gcloud CLI" instead of "local dev"
- Fix "Best for" on gcloud CLI tab to remove "developing" assumption
- Remove "Model names are the same as on Google AI Studio" claim
- Update troubleshooting to say "With gcloud CLI" instead of "On local dev"

Replace "For local development" with "With gcloud CLI" in the wizard
provider notes to match the docs tab naming convention.

The configPatch models.providers entry omits baseUrl (which is required
by ModelProviderConfig) because google-vertex constructs URLs dynamically
from project/location. Cast the configPatch as Partial<OpenClawConfig> so
TypeScript accepts the partial provider config.

The stricter tsgo type checker rejects a direct cast from the
configPatch object literal to Partial<OpenClawConfig> because the
models.providers entry omits baseUrl. Use the standard unknown
intermediate cast pattern.

- Expand auth bullet to list credential sources (metadata server,
  gcloud CLI, service account key) instead of just saying "ADC"
- Remove API key comparison from read_when frontmatter since this page
  does not cover API key / Express Mode auth
- Change "auth method" to "setup" since the three tabs are different
  credential sources for the same auth method, not different methods

The project's lint rules require curly braces around if bodies.

Run pnpm format:docs to fix table column alignment and add required
blank lines before closing Mintlify component tags.

The test expected getEnvApiKey("google-vertex") to return undefined when
GOOGLE_CLOUD_PROJECT is set but no credentials file exists. With the
relaxed auth gate, GOOGLE_CLOUD_PROJECT alone is sufficient to return
"<authenticated>" since the downstream transport handles actual
credential resolution at request time via google-auth-library.

Update the plugin manifest docs to describe the new env-vars-with-marker
auth evidence type alongside the existing local-file-with-env type.
Explains when to use each: local-file-with-env for credential files on
disk, env-vars-with-marker for ambient credential sources like GCE
metadata server or workload identity.

…istration

Fix two issues found by ClawSweeper re-review:

1. The configPatch in the google-vertex auth flow now reads existing
   models.providers["google-vertex"].models and merges the default model
   instead of replacing the array. Re-running onboarding no longer drops
   user-registered Vertex models.

2. applyPrimaryModel now only auto-registers models in models.providers
   for providers that already have a config entry. This prevents creating
   invalid provider config (missing baseUrl) for unknown custom providers
   when a user sets a manual slash-prefixed model.

Move the google-vertex API transport default from the core model
resolver (resolveProviderNameDefaultApi) into the Google plugin's
normalizeTransport hook. When the provider is google-vertex and no
api is explicitly set, the plugin now returns api: google-vertex.

This keeps provider-specific routing in the owning plugin instead of
the generic core resolver, matching the architectural pattern for
other provider plugins.

… path

Commit e4c0dd2 moved the google-vertex transport default from
resolveProviderNameDefaultApi in the core model resolver into the
Google plugin normalizeTransport hook. The hook only fires when
api is null/undefined, but the two fallback paths in model.ts
hardcode "openai-responses" as the default before the hook runs.
This caused google-vertex requests to route through the OpenAI
transport, sending the "gcp-vertex-credentials" marker as a literal
API key to platform.openai.com.

Restore resolveProviderNameDefaultApi in the core fallback chains
so it runs before the "openai-responses" default. Keep the plugin
hook as a redundant safety net for the discovered-model path.

Add inline comments at the three locations flagged by review:
- env-api-keys.ts: explain the intentionally permissive auth gate and
  where invalid setups fail (request time, not gate time)
- provider-contract-api.ts: document that onboarding writes are additive
  and reruns preserve existing models
- model-auth.profiles.test.ts: explain why the missing-explicit-path
  rejection test still passes with env-vars-with-marker evidence

…AuthEvidence

Discriminate the ProviderAuthEvidence union in the auth-presence loop so
hasLocalFileAuthEvidence is only called on the local-file variant (fixes
TS2345) and env-vars-with-marker evidence (ambient ADC) is satisfied by
its required env vars alone.

Gate google-vertex on a non-blank GOOGLE_CLOUD_PROJECT/GCLOUD_PROJECT
instead of also accepting a credentials file/env alone. A credentials
file without a configured project no longer authenticates, matching the
upstream 'requires non-blank project and location markers' expectation.
Remove the now-unused hasVertexAdcCredentials helper and its lazy
node-fs/os/path loader chain (credentials are resolved at request time
by the transport).

The onboarding AI access test (verifySetupInferenceConfig) ran the probe
with raw process.env and never applied the candidate config's env section,
so providers that resolve credentials from config env at request time (e.g.
google-vertex reading GOOGLE_CLOUD_PROJECT) failed the test even though they
work through the gateway and 'agent --local', which both call
applyConfigEnvVars. Apply the candidate config env around the probe,
mirroring gateway startup, and snapshot/restore so later onboarding steps
see the original environment.

… gemini-3.5-flash

Point the google-vertex catalog at current Vertex Gemini model IDs
(gemini-3.5-flash, gemini-3.6-flash, gemini-3.5-flash-lite, gemini-3.1-pro)
and default onboarding to gemini-3.5-flash, a Gemini 3 model that supports
thinking_level so the onboarding AI access test succeeds.

…schema

Upstream restructured the top-level config env section into a strict object
that only allows shellEnv and vars keys (src/config/zod-schema.root-shape.ts).
The onboarding auth flow still wrote GOOGLE_CLOUD_PROJECT/GOOGLE_CLOUD_LOCATION
directly under env, so onboarding config validation failed with
'Unrecognized keys' after syncing to latest upstream.

Nest the ADC env vars under env.vars so they satisfy the new schema and are
picked up by collectConfigEnvVarsByTarget. Update the google-vertex docs
config examples and prose to the env.vars shape.