Missing provider assertion in new tests

The two new tests don't assert that the returned model's provider field is "google". The PR description explicitly states that "the cloned model preserves the caller's original provider ID" — this is the key behavioral change introduced here. Without asserting provider: "google", a future accidental removal of provider: normalized from the patch object in model-forward-compat.ts would not be caught by these tests.

The provider field matters at runtime because it drives auth lookup and API key resolution (getApiKeyForModel uses model.provider). If provider were to silently revert to "google-gemini-cli", users who have credentials stored under "google" could face auth failures.

Suggested fix for both tests:

This is a comment left during a code review.
Path: src/agents/pi-embedded-runner/model.forward-compat.test.ts
Line: 90-112

Comment:
**Missing `provider` assertion in new tests**

The two new tests don't assert that the returned model's `provider` field is `"google"`. The PR description explicitly states that "the cloned model preserves the caller's original provider ID" — this is the key behavioral change introduced here. Without asserting `provider: "google"`, a future accidental removal of `provider: normalized` from the `patch` object in `model-forward-compat.ts` would not be caught by these tests.

The `provider` field matters at runtime because it drives auth lookup and API key resolution (`getApiKeyForModel` uses `model.provider`). If `provider` were to silently revert to `"google-gemini-cli"`, users who have credentials stored under `"google"` could face auth failures.

Suggested fix for both tests:
```suggestion
  it("builds a forward-compat fallback for google/gemini-3.1-flash-lite-preview", () => {
    mockGoogleGeminiCliFlashTemplateModel();
    const result = resolveModel("google", "gemini-3.1-flash-lite-preview", "/tmp/agent");
    expect(result.error).toBeUndefined();
    expect(result.model).toBeDefined();
    expect(result.model).toMatchObject({
      id: "gemini-3.1-flash-lite-preview",
      name: "gemini-3.1-flash-lite-preview",
      reasoning: true,
      provider: "google",
    });
  });

  it("builds a forward-compat fallback for google/gemini-3.1-pro-preview", () => {
    mockGoogleGeminiCliProTemplateModel();
    const result = resolveModel("google", "gemini-3.1-pro-preview", "/tmp/agent");
    expect(result.error).toBeUndefined();
    expect(result.model).toBeDefined();
    expect(result.model).toMatchObject({
      id: "gemini-3.1-pro-preview",
      name: "gemini-3.1-pro-preview",
      reasoning: true,
      provider: "google",
    });
  });
```

How can I resolve this? If you propose a fix, please make it concise.

Keep Gemini CLI schema sanitization active for google alias

Setting the cloned forward-compat model to provider: normalized makes google/gemini-3.1-* models carry provider google even though they still use the google-gemini-cli API template, and that bypasses the Google CLI tool-schema cleanup path because sanitizeToolsForGoogle only runs when provider is google-gemini-cli (src/agents/pi-embedded-runner/google.ts:248, called from src/agents/pi-embedded-runner/run/attempt.ts:797 and src/agents/pi-embedded-runner/compact.ts:390). In runs that use tools with unsupported schema keywords, this causes request failures that did not occur for the google-gemini-cli/... path.

Useful? React with 👍 / 👎.

Preserve gemini-cli auth provider for cloned 3.1 models

Overriding the cloned model to provider: normalized makes google/gemini-3.1-* forward-compat models report provider: "google" while still inheriting the google-gemini-cli transport fields from the template, and auth lookup is keyed by model.provider (src/agents/model-auth.ts, via getApiKeyForModel). In setups that only have google-gemini-cli OAuth profiles (the normal Cloud Code Assist path), these alias models now fail credential resolution because the runner looks for google credentials instead of google-gemini-cli.

Useful? React with 👍 / 👎.

Keep google provider on google forward-compat fallback

Accepting google in this guard now routes google/gemini-3.1-* through a google-gemini-cli template, so resolveModel returns early from forward-compat instead of using the configured models.providers.google fallback path; the resulting model carries Cloud Code Assist transport/auth metadata (model.provider is used by getApiKeyForModel), which breaks environments that only have Google API-key auth (GEMINI_API_KEY or providers.google.apiKey) and no google-gemini-cli credentials. This regression is triggered when a gemini-cli template is available in the registry.

Useful? React with 👍 / 👎.