#1558 Honor disabled MCP server overrides from higher-priority configuration

本文

## Title
Honor disabled MCP server overrides from higher-priority configuration

Issue: none (standalone correctness fix)

## Summary
A server disabled by a higher-priority MCP configuration remains enabled when a lower-priority configuration already defines it. `servers_from()` removes entries marked `disabled: true` before `hub_from_config()` merges the layers, so a later override cannot remove the earlier server.

For example, if the run config enables `notes` and `weather` but `--mcp-config` disables `notes`, the effective configuration incorrectly retains both.

## What changed
- Apply MCP configuration layers in priority order and remove earlier definitions explicitly disabled in a later layer.
- Preserve existing validation, ordinary replacement and the ability to re-enable a server in a subsequent layer.
- Add 10 regression tests covering disable/re-enable, configuration precedence, the last-server case, unrelated servers, invalid input and input non-mutation.
- **Unchanged:** MCP tool invocation, transport, server lifecycle and GPU/engine code.

## Extra Notes
**Before/after evidence:** Four of the ten new tests fail on upstream `main`; all ten pass with this fix.

**Validation actually executed:**
```text
python -m unittest serve.test_mcp_config_overlay serve.test_mcp -q
Ran 35 tests in 13.773s
OK
```
`git diff --check` passed.

Tested in a separate clean sparse checkout at upstream commit `fb58e0dbc8399662c0e47c76578c6e878b14f6cf` using a previously installed Python virtual environment. These tests use mock/local MCP servers. No production service, GPU inference, or full repository test suite was run.

**AI disclosure:** I used AI to help review the code and prepare the patch and tests. I ran the tests listed above locally.