Support HTTP Basic Auth (username/password) for custom MCP server connectors

Is your feature request related to a problem?

Please describe.

When adding a custom MCP server connector (products/mcp_store's custom-install flow, used e.g. by PostHog Code's "Add Custom MCP" UI), the only non-OAuth option is auth_type: "api_key". The proxy turns that into Authorization: Bearer <api_key> (see build_upstream_auth_headers in products/mcp_store/backend/proxy.py). Some third-party MCP servers — e.g. DataForSEO's remote MCP server (https://mcp.dataforseo.com/mcp) — require standard HTTP Basic Auth (Authorization: Basic base64(username:password), per RFC 7617) instead of a bearer token. Today there's no way to install this kind of server: choosing "API Key" sends the wrong header shape and the upstream server responds 401.

Describe the solution you'd like

Add a generic "basic" auth_type to the MCP Store custom-install flow:

• AUTH_TYPE_CHOICES in products/mcp_store/backend/models.py gains ("basic", "Basic Auth").
• InstallCustomSerializer accepts optional username/password fields when auth_type == "basic", stored encrypted in sensitive_configuration (same pattern already used for api_key).
• build_upstream_auth_headers() in proxy.py builds Authorization: Basic base64(username:password) server-side for that auth type; validate_installation_auth() rejects requests missing either field with the same "No credentials configured" shape used for api_key.
• The custom-install UI (e.g. PostHog Code's "Add Custom MCP" form) gets a "Basic Auth" option with Username + Password fields, mirroring the existing API Key field.

Because HTTP Basic Auth is a standardized scheme, this generalizes to any MCP server that requires Basic auth, not just DataForSEO.

Describe alternatives you've considered

• Client-side-only workaround: bypass the backend's install/proxy system entirely for servers like this, letting the local desktop MCP proxy talk directly to the upstream server with a user-supplied raw header map (similar to how Claude Desktop's custom MCP JSON config accepts arbitrary headers). This avoids any backend change, but stores secrets locally instead of in the backend's encrypted store and loses the centralized revocation/rotation the rest of this feature relies on — a worse fit for the existing security model.
• Reusing the existing api_key type by pasting a pre-encoded Basic token: doesn't work today because the api_key auth type unconditionally prefixes Bearer , and it wouldn't generalize into a real "Basic Auth" concept in the UI (no username/password separation, confusing for users who only have raw credentials).

Additional context

Found while trying to connect DataForSEO's MCP server (https://mcp.dataforseo.com/mcp) through the custom MCP connector flow, which requires a Base64-encoded username:password Basic Auth header. Relevant files: products/mcp_store/backend/models.py, products/mcp_store/backend/presentation/views.py (InstallCustomSerializer, install_custom), products/mcp_store/backend/proxy.py (build_upstream_auth_headers, validate_installation_auth).

DataForSEO's own docs for connecting over Basic auth: https://dataforseo.com/model-context-protocol

Read products/mcp_store/backend/models.py and presentation/views.py to trace custom-install validation and encrypted configuration, then inspect proxy.py for authentication header construction. Check how the custom-install UI represents auth choices and fields. Done means Basic Auth can be selected, username and password are stored securely, missing credentials are rejected, and upstream requests receive the standardized Basic authorization.