flat codegen: lower a user `impl transfer` body at its site

The largest remaining group in the flat corpus sweep (Vx#383) is the four programs whose transfer sema matched to a user lowering: backend/pass/custom_topology_user_lowering.vx, user_lowering_name_collisions.vx, user_lowering_uncountable.vx, user_lowering_waste.vx. flatten.rs declines at Expr::Transfer when t.lowering.is_some(), and the whole program falls to the AST path. Vx#353 tracks the feature; nothing tracks its flat-path half.

What the oracle does (codegen/lower/tensors.rs, hiraditya/Vx.1#353 A3)

It emits the vx.transfer with user_lowered so the C++ side keeps the allocation half (alloca, offsets, space propagation) and skips its own copy and barrier. Then it pastes the body into the site with (src, dst) bound to the source value and the placed tile. Inlined rather than called: a func.call inside a kernel region costs the kernel its device twin (isDeviceLowerableDialect excludes func).

The body is written against raw:: primitives (codegen/lower/mod.rs): extent (the static element count, with the linear-index unflattening the surface's flat indexing needs), load/store (memref.load/memref.store through that unflattening), barrier (gpu.barrier), async_copy (a load and a store today), async_wait (nothing).

What the flat path needs

1. raw:: opcodes. RawExtent, RawLoad, RawStore, RawBarrier, RawAsyncCopy/RawAsyncWait, with the same unflattening in the emitter as the oracle's (a linear i64 index over a rank-N static memref). The tensor operand is a memref value the flat path already carries.
2. The site. Transfer keeps its imm and grows a user_lowered flag (imm bit, or a second opcode) so the emitter writes the attribute and the C++ side behaves as for the oracle.
3. Inlining. The body is a Function on program.transfer_impls, checked with lowering_edge set. The clean shape is to lower it at the site in the HIR: bind its two parameters to the source register and the transfer's result register, then lower its statements as if written there, with the lowerer's binding maps saved and restored around it (the oracle learned that lesson the hard way; see the comment at the inlining site). A return inside the body ends the body, not the enclosing function, so lower_stmt needs a mode for that, the same one a value-if tail already has in spirit.
4. Names. user_lowering_name_collisions.vx exists because the oracle's flat name maps once leaked a body's let into the site. The HIR lowerer's scoped bindings make that a save/restore rather than a hazard, but the fixture will say.

Item 3 is the design choice: inline in the HIR (one lowerer, no new emitter machinery, but a body is lowered once per site) versus emit the body as a function and inline on the C++ side (one lowering, but the device-twin rule above has to be re-earned). The oracle chose the first; matching it keeps the two paths diffable.

The four fixtures run on both paths, so their CHECKs will need to hold on flat output as each lands.

Start with flatten.rs at Expr::Transfer and compare the oracle in codegen/lower/tensors.rs and raw primitives in codegen/lower/mod.rs. Trace transfer_impls, lowering_edge, and the HIR binding maps, then run the four fixtures—backend/pass/custom_topology_user_lowering.vx, user_lowering_name_collisions.vx, user_lowering_uncountable.vx, and user_lowering_waste.vx—on both paths; done means their CHECKs hold for flat output.