#990 MCP install planning rejects supported AMD CPU vision (and retains the old Windows HIP restriction)

本文

At v0.1.39 (`6f32ec070f23ced9f50e704d854d775da52591ab`), the MCP management server's install guards appear to lag behind the main installer's AMD support. This prevents an assistant using the documented MCP entry point from planning a supported installation even though the direct installer has a path for it.

## Reproduction: planning only, no model or GPU needed

Run `python3 tools/strata_mcp.py` from the checkout and send this single JSON-RPC line to stdin:

```json
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"strata_install","arguments":{"family":"qwen","model":"IQ2_XS","backend":"hip","vision":"cpu","confirm":false}}}
```

The response has `isError: true` and:

```text
images are not available on the AMD backend yet: use vision=no
```

This was reproduced on macOS arm64 / Python 3.14.5; no model, AMD inference, or installation was run. The failure is the unconditional planning guard in `tools/strata_mcp.py`, not a claim that macOS is supported. The same guard rejects the explicitly selected HIP CPU-vision combination before it reaches setup.

Expected: for a supported Linux AMD machine, `vision: cpu` can produce an install plan subject to the existing hardware, RAM and disk checks. `confirm: false` must still start no installation.

The fixed-version [AMD documentation](https://github.com/Niko1221/Strata/blob/6f32ec070f23ced9f50e704d854d775da52591ab/docs/AMD_HIP.md#L50) says Linux AMD supports the CPU encoder from v0.1.32. [setup.py's hip_vision](https://github.com/Niko1221/Strata/blob/6f32ec070f23ced9f50e704d854d775da52591ab/setup.py#L1904) has the corresponding path. In contrast, [the MCP guard](https://github.com/Niko1221/Strata/blob/6f32ec070f23ced9f50e704d854d775da52591ab/tools/strata_mcp.py#L1237) rejects every non-`no` vision option on HIP.

## Related source-only inconsistency

[Windows AMD text inference is documented from v0.1.34](https://github.com/Niko1221/Strata/blob/6f32ec070f23ced9f50e704d854d775da52591ab/docs/AMD_HIP.md#L59), while the MCP `install_plan` still rejects `backend == "hip" and WIN` outright. Its hardware discovery also collects AMD devices only in the non-Windows branch. I have not run this second case on a Windows AMD machine.

Would it make sense for the MCP controller to share the current installer's backend/vision support rules, so the two advertised setup paths stay aligned? A small planning test matrix for Linux HIP CPU vision, Windows HIP text-only, and genuinely unsupported Windows HIP vision would help prevent drift.