Bug Description

The VertexAI Provider object stored in Redux has a fundamental type mismatch with the VertexProvider type definition! This leads to code relying on false type assertions and complex runtime mappings.

Problem Symptoms

1. Type System Lies - The isVertexProvider() function only checks the type field but claims to return a VertexProvider type containing googleCredentials and project fields
2. Scattered Data Storage - VertexAI configuration is stored in two places:
   • Provider object in llm.providers[] (basic configuration)
   • llm.settings.vertexai (sensitive configuration)
3. Inconsistent Field Naming - Redux state uses serviceAccount/projectId, but type definitions expect googleCredentials/project
4. Manual Mapping Required - All code using VertexAI must call createVertexProvider() for mapping, which is error-prone

Proof

The following code locations all require defensive checks or explicit mapping, indicating the type system is untrustworthy:

• src/renderer/src/utils/provider.ts:159-161 - isVertexProvider() false type assertion
• src/renderer/src/hooks/useVertexAI.ts:46-59 - Must call createVertexProvider() for mapping
• src/renderer/src/aiCore/legacy/clients/gemini/VertexAPIClient.ts:26-30 - Needs to check if it's really a VertexProvider, otherwise manually map
• src/renderer/src/aiCore/provider/providerConfig.ts:321-335 - Must call createVertexProvider() to get configuration

Redux Actual Storage

// Provider object in llm.providers[]:
{
  id: 'vertexai'
  type: 'vertexai'        ✓
  apiKey: string          ✓
  apiHost: string         ✓
  // ❌ Missing googleCredentials, project, location
}

// Real configuration is in llm.settings.vertexai:
{
  serviceAccount: {           // ❌ Should be called googleCredentials
    privateKey: string
    clientEmail: string
  }
  projectId: string          // ❌ Should be called project
  location: string
}

Expected Behavior

VertexAI configuration should have a single source of truth, and the type system should accurately reflect the actual data structure!

Steps To Reproduce

1. View the VertexProvider type definition in src/renderer/src/types/provider.ts
2. View the storage structure in Redux state src/renderer/src/store/llm.ts
3. Check the implementation of the isVertexProvider() function
4. Trace all code paths using VertexAI configuration

Expected Behavior

1. The type system should accurately reflect the runtime data structure
2. VertexAI configuration should be stored in a single, consistent location
3. No complex mapping functions and defensive checks are needed

Additional Context

This is an architectural design flaw, not a user-visible bug. But it leads to:

• Difficult code maintenance
• Easy to introduce bugs (type mismatch)
• Runtime performance overhead (mapping functions)
• Poor developer experience (type system cannot help developers)

Need to refactor the VertexAI Provider data storage architecture!

// llm.providers[] 中的 Provider 对象：
{
  id: 'vertexai'
  type: 'vertexai'        ✓
  apiKey: string          ✓
  apiHost: string         ✓
  // ❌ 缺少 googleCredentials、project、location
}

// 真实配置在 llm.settings.vertexai 中：
{
  serviceAccount: {           // ❌ 应该叫 googleCredentials
    privateKey: string
    clientEmail: string
  }
  projectId: string          // ❌ 应该叫 project
  location: string
}