fix: config precedence now correctly allows local config to override remote

[elithrar]

Fixes an issue where remote config from .well-known/opencode overrides local config instead of the other way around.

problem: Remote config was loaded last in the config precedence chain, meaning organizational defaults (like enabled: false on MCP servers) couldn't be overridden by users in their local config.

example: we ship MCP servers configured (for discovery!) but disabled (to avoid context bloat) as below. The current config merging prevents a user from having mcp: { "jira": { "enabled": true } } in their local config to enable JIRA (and retain all other settings).

    "mcp": {
      "jira": {
        "type": "remote",
        "url": "https://jira.mcp.example.org/mcp",
        "enabled": false,
        "oauth": {

        }
      },
      "wiki": {
        "type": "remote",
        "url": "https://wiki.mcp.example.org/mcp",
        "enabled": false,
        "oauth": {

        }
      },
      "gitlab": {
        "type": "remote",
        "url": "https://gitlab.mcp.example.org/mcp",
        "enabled": false,
        "oauth": {

        }
      },

solution: Reorder config loading so remote config loads first as the base layer:

1. Remote config (.well-known/opencode) — organizational defaults
2. Global config (~/.config/opencode/) — user preferences
3. Project config (opencode.json) — project-specific overrides

Users can now enable MCP servers that organizations disable by default:

{ "mcp": { "jira": { "enabled": true } } }

Remote config fetch failures still hard-fail (as before) but now with a clearer error message showing the URL and HTTP status.