`owning_topology` picks device 0 when a space names a kind, not an instance

TransferCostGraph::owning_topology (added in d8fc59c3) answers which device holds a memory space. For the kinds that carry an index it answers with index 0:

K::GPU => Topology::GPU(zero()),
K::NPU | K::Slice => Topology::NPU(zero()),
K::AccCore => Topology::AccCore(zero()),

So Memory::GPU_HBM on a two-GPU machine resolves to Topology::GPU[0], silently. That is the shape of choice Vx#424 rules out everywhere else: a space claimed by two topologies is an error rather than a first-wins pick, and this is the same ambiguity one level down — the kind is derivable, the instance is not.

It is not wrong today, because a space names a kind and nothing in the corpus has two devices of one kind whose memories are distinguished. tests/optimizations/pass/two_gpu_devices.vx has two GPUs, but places by topology rather than by space, so it never asks.

What it would take to be right

A space would have to name an instance, which means either

• Memory::GPU_HBM[1] as a spelling, parallel to Topology::GPU[1]; or
• the placement being written as a topology whenever the instance matters, and Memory::X being rejected where more than one device of the owning kind exists.

The second is closer to the rule as stated — if the device cannot be told, say so — and needs no new syntax. It does need the compiler to know how many devices of a kind the target has, which is a machine-description question rather than a type-system one.

Related, and worse

Memory::Remote_HBM is the host's provisionally, and that is a placeholder rather than an answer. Its meaning is memory on another machine — it is what vx_plugin_transfer_peer moves between and what Vx#347's disaggregated prefill/decode split is built on. Naming its owner needs a topology that refers to a remote node, which the type system cannot express at all. Whatever Vx#347 needs there supersedes the current placeholder.

Start with TransferCostGraph::owning_topology and compare its kind-to-instance handling with Vx#424. Run tests/optimizations/pass/two_gpu_devices.vx to understand the existing two-GPU behavior, then review Vx#347's remote-memory implications. Done means the ambiguity is rejected or otherwise represented explicitly, with coverage for multiple devices of one kind.