feat: add deepseek channel type and fix channel connectivity test

[BeiBaiNian]

Why

The channel connectivity test (the "Test" button) failed or was unavailable for most channel types:

1. claude and gemini channels could never be tested: the backend rejected them with "the X channel type is not supported yet in this stage" even though the UI lets users create them and fill in their API keys.
2. openai (and claude) channels with the UI's default base URL (https://api.openai.com/v1, which already includes "/v1") were probed at "/v1/v1/models", which returns 404, so the test always failed even with a valid key.
3. When the gateway runs in a network that requires a proxy to reach upstream LLM providers (e.g. Google/OpenAI are unreachable from the deployment region), the probe did not honor any proxy setting and timed out with "context deadline exceeded".
4. The UI had no DeepSeek channel type, one of the mainstream OpenAI-compatible providers.

This PR makes the connectivity test work for every channel type the UI offers (as long as the API key is configured), adds first-class DeepSeek support, and makes the probe respect the existing httpProxy configuration.

What changed

Backend:

• object/channel.go

  • Added "deepseek" to channelTypes and openAiCompatibleChannelTypes, so DeepSeek channels can be saved and can be routed by the gateway (DeepSeek speaks the OpenAI wire format natively).
  • Reworked TestChannelConnectivity to dispatch the probe per channel type instead of rejecting non-OpenAI-compatible types up front: openai/deepseek/custom/claude probe {base}/v1/models with Bearer auth (claude also sends x-api-key and anthropic-version), gemini probes {base}/models?key=... Unknown types still return the "not supported" error.
  • Added openAiCompatibleModelsUrl: when the base URL already ends with "/v1" (the UI default for openai/claude), "/models" is appended instead of "/v1/models", fixing the 404 caused by the doubled "/v1".
  • The probe result (success and failure, including network errors) now includes the exact URL that was requested, e.g. "404 Not Found (GET https://api.openai.com/v1/v1/models)", so problems are visible directly in the UI.
  • The probe HTTP client now comes from proxy.GetProxyHttpClient(), honoring the httpProxy setting in app.conf.

• proxy/proxy.go

  • Exported getProxyHttpClient as GetProxyHttpClient and added support for "http://host:port" / "https://host:port" proxies (HTTP proxies such as Clash at http://127.0.0.1:7899). A bare "host:port" value keeps the legacy SOCKS5 behavior.

Frontend:

• web/src/ChannelEditPage.js

  • Added DeepSeek to the type selector.
  • Added deepseek to BASE_URL_PRESETS (https://api.deepseek.com) and MODEL_PRESETS (deepseek-v4-flash, deepseek-v4-pro, the models currently returned by the official DeepSeek API), and removed the DeepSeek leftovers from the custom presets.
  • The test result panel now shows the backend message directly, which includes the actual probe URL.

• web/src/ChannelListPage.js

  • Added a deepseek tag color (#4d6bfe).

Verification

• Reproduced before the fix (local):

  • An openai channel with base_url https://api.openai.com/v1 got 404 from the doubled path: GET https://api.openai.com/v1/v1/models → 404, while GET https://api.openai.com/v1/models with the same key → 200.
  • A gemini channel was rejected with "the gemini channel type is not supported yet in this stage"; a direct request to https://generativelanguage.googleapis.com/v1beta/models?key=... with the stored key returned 200 with the model list, proving the key and network were fine.
  • Without a proxy the probe to Google timed out after 8s ("context deadline exceeded"); through the local HTTP proxy (http://127.0.0.1:7899) it responded in ~0.3s.

• After the fix (manual local build & test):

  • gemini_test: Connection Successful.
  • deepseek_test: Connection Successful with a real key.
  • openai_test: the key is known valid (200 above); final regression pending local rebuild.