Placement heuristics choose between zone copies of a home site arbitrarily on multi-zone specs #1055

Background

#1053 made home positions per zone across every zone. The word template is spec-wide, so ArchSpec.home_sites now holds the same (word_id, site_id) once for each zone where that word isn't a staging word. The Python placement heuristics predate this. They either rank candidates by word and site IDs only, or fix a single zone per word through word_zone_map. So on a multi-zone spec, the zone an atom goes to is decided by set iteration order or by a "first zone that references the word" rule, not by any placement policy.

Both bundled Gemini specs are single-zone, so nothing shipped is affected today. This is a design gap to settle before multi-zone archs go through these heuristics. Copilot raised part of it on #1053, where it was out of scope.

Where

Logical placement (python/bloqade/lanes/heuristics/logical/placement.py)

• _distance_key returns (word_distance, site_distance, word_id, site_id), with no zone term and no reachability check. _nearest_home_layout takes min(available_home, key=_distance_key), so a returning atom ties between the gate and storage copies of a site. It can land on a copy that has no path from its current position.
• The lookahead path builds holes = sorted(home_sites - used_home, key=lambda x: (x.word_id, x.site_id)). Zone copies compare equal, so their order comes from set iteration.

Logical layout (python/bloqade/lanes/heuristics/logical/layout.py)

• The initial candidates are set(arch_spec.home_sites) - pinned, and ties break on (score, word_id, site_id), again with no zone term.
• The capacity message reports len(home_sites) as "total sites". On a multi-zone spec that counts every zone copy, which may not be the intended capacity.

Physical layout (python/bloqade/lanes/heuristics/physical/layout.py)

• _sites_center_out, _sites_bottom_up and _candidate_slots choose the zone for a home word as arch_spec.word_zone_map[word_id]. This is the first zone whose pairs, word buses or words_with_site_buses reference the word, else zone 0. After fix(arch): decide home positions per zone across every zone #1053 this is word_zone_map's only production caller, and its docs now describe it as a placement preference rather than ownership.

What needs deciding

Where should atoms start and return to on a spec with more than one zone? Options include:

• the entangling zone(s) only;
• the nearest reachable copy;
• storage, if one exists, as a separate "return to storage" NoHome-style policy.

Whatever the answer, it should be one explicit policy that all four sites share, with zone and reachability as real terms. Once it lands, word_zone_map can likely be deprecated.

Include a multi-zone storage test. Note that several existing multi-zone fixtures put two words on the same grid point, which models word ownership rather than the spec-wide template, and shouldn't be used for this: _build_two_zone_spec in python/tests/layout/test_arch.py, and the fixture in python/tests/bytecode/test_zone_bus_search.py.

Related: #1053, #1054.