The flat path drops a transfer's space name and a spawn region's topology name

Now that middle_end/pass/topology.vx compiles through the flat path (a39b27dd and the commit after it, Vx#409), the two paths can be diffed on a program with a transfer and a spawn on. They agree on the ABI. They do not agree on two attributes.

oracle:  %0 = "vx.transfer"(%arg0) <{target_topology = 100 : i32}> {space = "NPU_HBM"} : ...
flat:    %0 = "vx.transfer"(%arg0) <{target_topology = 100 : i32}> : ...

oracle:  } {topology_name = "NPU[0]"}
flat:    }

Why

The flat emitter attaches space only when ctx.subspaces has a descriptor for the transfer's dispatch id — that is, when the program declares a sub-space with within/granule/capacity. Memory::NPU_HBM is a builtin space with no declaration, so nothing attaches the name.

The oracle attaches it unconditionally, from the MemorySpace it still has in hand. The flat path has only Opcode::Transfer's imm, the dispatch id.

How much is recoverable

More than I first assumed. arch::memory_space_dispatch_id gives the builtin spaces distinct ids — CPU_DRAM 0, NPU_HBM 100, LocalSRAM 200, GPU_HBM 500, NicRam 800, RemoteHbm 900 — so a reverse lookup over the builtins recovers the name exactly. Only MemorySpace::Custom(name) cannot be inverted: its id is fnv_dispatch_id(name), a hash. A declared custom space already reaches the emitter through ctx.subspaces, so the two mechanisms together may cover everything; that wants checking rather than assuming.

What it costs today

Nothing that runs. codegen/lower/tensors.rs says so where it attaches the attribute: "A later vx.* pass reads this to schedule tiles into sub-spaces (TMEM/SMEM); it does not affect lowering." So this is scheduling metadata, and no current pass consumes it for a builtin space.

It matters because the flat path is meant to be a faithful second implementation, and "emits strictly less metadata than the oracle" is the kind of difference that is invisible until something starts reading it. flat_carries_subspace_scheduling_metadata already pins the declared-sub-space case; nothing pins this one.

Also unexplained, from the same diff: the oracle emits a trailing %c0 = arith.constant 0 : index after the spawn region that the flat path does not. Recorded as observed rather than diagnosed.

Related: Vx#383 (the coverage campaign this surfaced from), Vx#393 (the oracle's unconditional printMemref declarations, the other standing difference between the two).

Start with codegen/lower/tensors.rs and compare how the flat emitter and oracle attach transfer space and spawn topology_name metadata, using middle_end/pass/topology.vx as the reproduction. Check the builtin dispatch IDs and the existing flat_carries_subspace_scheduling_metadata test. Done means the paths agree for builtin and declared custom spaces, with tests covering the recovered attributes and the observed trailing constant handled or explicitly scoped.