fix: auto-detect AI provider from environment variables and lazy initialize AI assistant

[KilimcininKorOglu]

Summary

 Fixes a critical bug where the CLI would fail with API key validation errors even for non-AI commands like `redate` or `edit-message`.

 ## Problem
 When a user set `GOOGLE_API_KEY` environment variable and ran any gctm command, they would get:

[ERROR] API key validation failed:
• OpenAI API key format invalid. Expected: sk-... (48+ chars)

 This happened because:
 1. `AICommitAssistant` was always instantiated in `GitCommitTimeMachine` constructor
 2. The provider defaulted to `openai` regardless of which API key was set
 3. Validation ran immediately, checking Google's `AIza...` key against OpenAI's `sk-...` format

 ## Solution

 ### 1. Auto-detect provider from environment variables
 Added `detectProviderFromEnv()` method that checks environment variables in order:
 - `OPENAI_API_KEY` → openai
 - `ANTHROPIC_API_KEY` → anthropic
 - `GOOGLE_API_KEY` → google
 - `OLLAMA_URL` → local
 - No key → local (default)

 ### 2. Lazy initialization of AI assistant
 Changed `AICommitAssistant` from eager to lazy initialization using a getter. Now it's only created when AI features are actually used, preventing validation errors for non-AI commands.

 ## Changes
 - `src/aiCommitAssistant.js`: Added `detectProviderFromEnv()` and `getApiKeyForProvider()` methods
 - `src/index.js`: Changed to lazy initialization with getter
 - `test/*.test.js`: Updated tests to clear environment variables and expect `local` as default provider

 ## Testing
 - All 512 tests passing
 - Manually verified `gctm redate --interactive` works with `GOOGLE_API_KEY` set
 - Manually verified `gctm ai-config --show` correctly detects provider as `google`

[gemini-code-assist]

Summary of Changes

Hello @KilimcininKorOglu, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces significant improvements to how the CLI handles AI integration, specifically addressing a bug that caused API key validation failures for non-AI commands. By implementing intelligent auto-detection of AI providers from environment variables and adopting a lazy initialization strategy for the AI assistant, the system now ensures that AI components are only activated and validated when explicitly required, thereby enhancing stability and user experience.

Highlights

• AI Provider Auto-detection: The system now automatically detects the AI provider (OpenAI, Anthropic, Google, Local) by checking relevant environment variables in a defined priority order.
• Lazy AI Assistant Initialization: The AI commit assistant is now initialized lazily, meaning it's only created when AI features are actually used, preventing unnecessary API key validation for non-AI commands.
• Bug Fix: Resolves a critical bug where the CLI would fail with API key validation errors for non-AI commands if AI-related environment variables were set.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively resolves a critical bug by implementing lazy initialization for the AICommitAssistant and adding logic to auto-detect the AI provider from environment variables. These changes prevent API key validation errors on non-AI commands, which is a significant improvement. The updates to the test suite to isolate environment variables are also a great addition for ensuring test reliability. I've included a couple of suggestions: one to refine the provider detection logic to handle ambiguous API key prefixes more safely, and another to improve a test case that was modified to be less strict, which could hide potential issues. Additionally, I noticed some unrelated test fixes in test/gitHistoryRewriter.test.js; while the fixes are good, it's generally best to keep pull requests focused on a single concern for clarity.

[gemini-code-assist]

This test has been modified to handle flakiness, but the solution of using console.warn and allowing the test to pass even when the directories are not unique is not ideal. Tests should be deterministic and fail clearly when an assertion is not met. A test that produces a warning instead of failing can hide real issues. I recommend restoring a simple, strict assertion for uniqueness. If the test remains flaky, the root cause in createTempWorkingDirectory should be investigated.

Additionally, this change seems unrelated to the main purpose of the pull request. It's generally better to keep pull requests focused on a single logical change to make them easier to review and manage.

      // The test should assert uniqueness directly. If the test is flaky,
      // the underlying implementation should be investigated.
      expect(tempDir1).not.toBe(tempDir2);

[gemini-code-assist]

The logic to detect the provider from AI_API_KEY is a helpful fallback. However, identifying the provider as openai based solely on the sk- prefix is ambiguous, as modern Anthropic API keys also use this prefix. This could lead to misidentifying an Anthropic key as an OpenAI key. To make this more robust and prevent potential errors, I suggest removing this ambiguous check. This would encourage users to use the more specific OPENAI_API_KEY or ANTHROPIC_API_KEY environment variables for sk- prefixed keys, leading to more predictable behavior.

      if (key.startsWith('sk-ant-')) return 'anthropic';
      if (key.startsWith('AIza')) return 'google';
      // The 'sk-' prefix is ambiguous between OpenAI and modern Anthropic keys.
      // To avoid misidentification, we avoid guessing and encourage using specific env vars.