Bound the parallel pressure-advance lookup to the filament count

Review findings on the preceding commit, plus one defect it should have
caught.

- The IDEX/IQEX pressure-advance loop fed resolve_filament_for_head()'s
  result straight into enable_pressure_advance and pressure_advance. That
  result is bounded by physical_extruder_map, which holds one entry per
  NOZZLE, while both options are indexed per filament SLOT. On a printer
  with more nozzles than the project has filaments the two spaces diverge
  and get_at() clamped the overflow onto filament 0, emitting its pressure
  advance on a secondary carriage. The second-layer temperature loop bounds the
  same lookup, but against nozzle_temperature, which is variant-expanded and so
  is not the slot count either -- it is not the precedent it looks like.
  IMEXHelpers.hpp states the rule
  once, and a test pins the contract that makes the bound necessary:
  resolve_filament_for_head() answers in nozzle space, so a non-negative
  result is not by itself safe to use as a filament id.

- The header claimed every caller renders a -1 tool qualifier as "emit
  none". RepRapFirmware substitutes the historical D0 instead, deliberately
  and with its own comment in GCodeWriter. Say so, rather than leaving a
  contract a future author would code against.

- A cross-reference pointed at a hard-coded line number that the preceding
  commit had itself shifted by nine lines. Name the function instead.

- The multi-color rejection reasons reach the user through Print::validate()
  as raw English, while the returns on either side of them use L(). Wrap
  them and register IMEXHelpers.cpp for extraction. They also still said
  "IMEX", the internal name, so they move to IDEX/IQEX with the rest of the
  user-facing strings rather than shipping the internal one to translators.

- Trim the preceding commit's comments. One block explained the same
  clamping hazard six times; the canonical explanation now lives in
  IMEXHelpers.hpp and the call sites point at it. The mode grid carried
  twelve lines of commentary and no code, most of it archaeology already in
  the commit message, and one claim about the modes editor that was not
  true. The ArrangeJob threading note stays: it documents an invariant that
  cannot be recovered from the code.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/slic3r/GUI/IMEXModesCtrl.cpp

@@ -408,18 +408,10 @@ void IMEXModesCtrl::add_row(const std::string& name,
     // raw_row = flip_y ? (n_rows-1-row) : row
     // raw_col = flip_x ? (n_cols-1-col) : col
     //
-    // The displayed window is always the whole grid: m_n_rows is the gantry count, so valid tool
-    // indices are 0 .. m_n_rows*m_n_cols-1 and rows 0 .. m_n_rows-1. A window m_n_rows tall can
-    // only lie entirely inside the grid when it starts at row 0.
-    //
-    // This used to anchor the window's first row to the Primary's gantry row, to "keep the
-    // meaningful row visible" when the gantry count shrank. That cannot work: shifting a
-    // full-height window forward walks it off the end, so it drew tiles for tools that do not
-    // exist and hid real ones, and clicking a phantom tile wrote a tool index that
-    // compute_imex_zone_layout() (IMEXZones.cpp:76) then discards. A Primary sitting outside the
-    // current grid is a data problem -- only reachable from a hand-authored mode string, since
-    // the editor will not move Primary off tool 0 -- and the zone layout already answers it by
-    // producing no zones at all. Showing the real grid is the honest rendering of that state.
+    // Render the whole grid: m_n_rows is the gantry count, so the valid tool indices are
+    // 0 .. m_n_rows*m_n_cols-1 and a window this tall only fits inside the grid at row 0.
+    // A Primary outside the grid is a data problem the zone layout already reports by
+    // producing no zones (compute_imex_zone_layout, IMEXZones.cpp).
 
     bool flip_x = (m_layout == 1 || m_layout == 3);
     bool flip_y = (m_layout == 2 || m_layout == 3);