fix: forward providerType to chat API for custom provider support

[nkmohit]

Summary

Fixes chat failures for custom LLM providers by forwarding providerType and requiresApiKey through the chat request path and resolving chat models with the shared resolveModel() helper. Previously, /api/chat used an older provider resolution path and could fail with Unknown provider: custom-... Please provide providerType. for custom providers that worked elsewhere in the app.

Related Issues

Fixes #116

Changes

• Added providerType and requiresApiKey to StatelessChatRequest
• Forwarded provider metadata from components/chat/use-chat-sessions.ts in chat, resume, and discussion request flows
• Refactored app/api/chat/route.ts to use the shared resolveModel() helper
• Removed the older manual chat provider resolution path that could not resolve custom-* providers without explicit provider metadata

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Refactoring (no functional changes)
• CI/CD or build changes

Verification

Steps to reproduce / test

1. Configure a custom provider in Settings with a valid provider type, base URL, and model
2. Select that custom provider/model in the app
3. Send a message in the chat UI
4. Confirm chat no longer fails with Unknown provider: custom-... Please provide providerType.

What you personally verified

• Verified the chat request type and payload now include providerType and requiresApiKey
• Verified /api/chat now resolves models through resolveModel(), matching the provider-aware path used by other API routes
• Ran pnpm exec tsc --noEmit
• Ran pnpm lint app/api/chat/route.ts components/chat/use-chat-sessions.ts lib/types/chat.ts
• Ran pnpm build
• Verified GET /api/health returned success locally
• Verified a direct POST /api/chat request with a custom provider model and providerType streamed a normal SSE response instead of returning the previous 500
• Verified the old failure still reproduces if providerType is omitted, confirming the fix addresses the intended bug

Evidence

• CI passes (pnpm check && pnpm lint && npx tsc --noEmit)
• Manually tested locally
• Screenshots / recordings attached (if UI changes)
  before:

after:

Checklist

• My code follows the project's coding style
• I have performed a self-review of my code
• I have added/updated documentation as needed
• My changes do not introduce new warnings