Scope: decouple cuopt_mcp from the cuopt package

Goal

Make cuopt_mcp a pure-Python, CUDA-free wheel so an MCP client can install it
on a laptop (uvx cuopt-mcp) and talk to a remote cuopt_grpc_server. This is
what server.py already claims — "the host needs no GPU" — and what today's
packaging contradicts, since installing it pulls cuopt-cu13 and the CUDA
runtime onto a machine whose only job is to open a socket.

Secondary payoff: the CUDA-suffixed wheel matrix, the conda recipe and the
per-platform CI jobs all collapse to one py3-none-any artifact. That matters
now because none of that wiring exists yet — this decides what gets built.

What already exists (do not rebuild)

schema.py's docstring already states the principle: "Nothing here
hand-maintains a second copy of the settings surface." This work extends that
from settings to problem and solution arrays.

The five couplings to remove

cuopt_mcp imports exactly five symbols from cuopt, all lazily:

DataModel is the one worth calling out: today the MCP converts JSON arrays →
DataModel → the C++ client takes it apart again into arrays on the wire. The
MCP's JSON input is already the wire shape. Removing the middle step removes a
CUDA-linked C++ type that exists only to be disassembled.

Design

Three layers, smallest first.

1. Transport. grpcio + stubs generated by grpcio-tools from the two
existing protos. Generated at build time and committed alongside the other
codegen output, so ci/verify_grpc_codegen.sh covers drift.

2. Mapping. JSON arrays ↔ proto messages. Emitted from field_registry.yaml
by a new generate_python_mapping() in generate_conversions.py, sitting
beside the existing generate_mcp_schema(). A field added to the registry then
appears on the C++ side, the proto, the MCP schema and the Python mapper — or
CI fails. There is no second interface to drift because there is no
hand-written interface.

3. Tools. tools.py / client.py swap their imports. The tool surface,
JSON contract and tests are unchanged — the existing 63 tests are the
regression suite for this refactor.

Phasing

Phase 1 — unary only. GRPC_INTERFACE.md explicitly offers this: "Stick to
unary SubmitJob/GetResult and raise max_message_bytes on both sides… a custom
client can send any problem up to ~2 GiB or so as a single round-trip and skip
the chunked machinery entirely." This removes the largest risk from the
critical path. Ships a working CUDA-free MCP.

Phase 2 — chunked path, only if needed. StartChunkedUpload /
SendArrayChunk / FinishChunkedUpload and the download mirror. Needed only
for problems past ~2 GiB, or for throughput (the doc measures ~580 MB/s chunked
vs ~280 MB/s unary on a 706 MB problem). Defer until a real workload asks.

Open decisions

1. MPS/LP/QPS parsing (Read). Options: (a) drop problem_path, JSON-only;
   (b) add an RPC that ships file bytes and parses server-side; (c) pure-Python
   parser. Recommend (b) — it keeps the feature, puts parsing where the C++
   parser already lives, and lets a remote user submit an MPS file with no local
   cuOpt. Costs a proto addition, so it wants Trevor's view.
2. Package name. Dropping the dependency makes cuopt-mcp (unsuffixed)
   correct, via disable-cuda = true. Verified: that flag alone un-suffixes the
   name and the dependency, which is only safe once the dependency is gone.
3. Does cuopt_mcp stay in this repo? In-repo keeps it next to
   field_registry.yaml, which is what makes the generated mapper trustworthy.
   Recommend staying.

Non-goals

• Replacing the Cython client. It stays the client for in-process/GPU users.
• Routing/VRP over MCP.
• Chunking in phase 1.

Risks

• Two implementations of the wire protocol. Mitigated by generating the
  mapper from the registry and covering it with verify_grpc_codegen.sh; not
  eliminated. The chunking layer in phase 2 would be genuinely hand-written and
  is the real drift risk — another argument for deferring it.
• Endianness. ArrayChunk.data is "raw native-endian element bytes". A
  Python client must match; numpy.tobytes() is native-endian, so this is fine
  in practice but needs an explicit test.
• Scope creep into a general Python client. The deliverable is an MCP
  server, not a supported public Python gRPC client. Keep the generated mapper
  private to the package until someone asks otherwise.

Rough effort