…t default

Add a static model catalog for the google-vertex provider, following the
same pattern as the google (AI Studio) provider's runtime catalog. The
catalog includes:

- Auto-updating latest aliases: gemini-flash-latest (default),
  gemini-pro-latest, gemini-flash-lite-latest
- Shared Gemini text models from the existing google catalog:
  gemini-3.1-pro-preview, gemini-3-flash-preview

The latest aliases always point to the latest stable model in each family
and are recommended for most users. gemini-flash-latest is tagged as the
default model and is set as the wizard default for new google-vertex
setups.

Update the docs page to document both latest aliases (recommended) and
specific version model IDs.

Change the google-vertex setup.providers authMethods from "api-key" to
"adc" so the auto-generated wizard choice matches our ADC auth method.

Previously the manifest declared authMethods: ["api-key"] but the
google-vertex provider had no auth method with id "api-key" (and the
original provider had auth: [] entirely). The wizard generated a choice
ID "google-vertex-api-key" that matched nothing, so selecting
"Google Vertex" in onboarding skipped the auth flow entirely.

Now the wizard generates "google-vertex-adc" which matches our ADC auth
method, triggering project auto-detection and config writing.

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.

The missing-model registration hint now includes both id and name
fields (commit 0152bcc). Update the test assertion to expect the
new format.

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