docs(web): clarify custom provider config scope and baseURL

[edlsh]

Clarifies global vs project config for custom providers, adds OpenAI-compatible (custom) provider example with options.baseURL (host), apiKey, and headers in /docs/config, plus updates /docs/providers.

[github-actions]

Hey! Your PR title Docs: clarify custom provider config scope and baseURL doesn't follow conventional commit format.

Please update it to start with one of:

• feat: or feat(scope): new feature
• fix: or fix(scope): bug fix
• docs: or docs(scope): documentation changes
• chore: or chore(scope): maintenance tasks
• refactor: or refactor(scope): code refactoring
• test: or test(scope): adding or updating tests

Where scope is the package name (e.g., app, desktop, opencode).

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search results, I found the following potentially related PRs:

Most Relevant:

1. PR feat: add excludeDefaultOptions for custom API compatibility #7760 - "feat: add excludeDefaultOptions for custom API compatibility"

   • Related to custom provider configuration and API compatibility options

2. PR feat(opencode): add auto model detection for OpenAI-compatible providers #8359 - "feat(opencode): add auto model detection for OpenAI-compatible providers"

   • Directly related to OpenAI-compatible provider support

3. PR Adding the auto-detection of ollama local with a variable for baseURL #3726 - "Adding the auto-detection of ollama local with a variable for baseURL"

   • Related to baseURL configuration for custom providers

4. PR feat: add custom provider support to GitHub Action #1488 - "feat: add custom provider support to GitHub Action"

   • Adds custom provider support functionality

These PRs appear to be related to custom provider configuration, OpenAI-compatible providers, and baseURL settings, which overlap with the scope of PR #9612. However, none appear to be exact duplicates - they seem to address related but distinct aspects of custom provider functionality and documentation.

[edlsh]

One minor addition to consider: the code also accepts options.endpoint as an alias for options.baseURL (with endpoint taking precedence if both are specified). See provider.ts#L226:

const endpoint = providerConfig?.options?.endpoint ?? providerConfig?.options?.baseURL

Might be worth mentioning this for users migrating from other tools that use endpoint terminology.