CAD: the mate palette fired nothing — two menu handlers were shadowing it

Right-clicking a document with two coordinate systems builds the mate palette
exactly as designed: a separator, a disabled "Mate: A -> B" header, then five
rows in fixed order. Hovering a row showed no ghost and left the previous status
message on screen; clicking one created nothing at all. The palette enumerated
perfectly and fired nothing, which put the whole M8 mate epic out of reach from
the UI.

The mate handlers were never invoked. show_offer_menu binds two pairs of
handlers to the SAME wxMenu: the mate pair (by mate_base, at base + 500) and the
generic verb pair. wxWidgets pushes dynamic entries to the FRONT of the handler
list, so the pair bound LAST runs FIRST for every id — and the generic pair was
last. A mate id lands outside the verb table's range, so both generic lambdas
returned early WITHOUT e.Skip(), which wx reads as "handled", and the mate
handlers behind them never saw the event.

Binds the two generic handlers to the verb id range [base, base + 499] so each
half only sees its own ids regardless of bind order.

Verified on the rig with a purpose-built assembly (two bodies 60 mm apart, a
Coord Sys on each): before, clicking Fastened produced no feature and no status
change; after, it produces a Mate feature. The verb rows keep working — the same
run created both coordinate systems through Reference > Coord Sys.

Note the mate then fails its recompute with "mate: mate_cs_b has no associated
body", because a Point(world) coordinate system belongs to no body while the
palette still advertises all five kinds as viable. That is a separate defect and
is filed; this commit is about the palette being reachable at all.

src/slic3r/GUI/DesignPanel.cpp

@@ -5786,6 +5786,14 @@ void DesignPanel::show_offer_menu(const wxPoint& screen_pos)
 
     // Hovering a row explains it. The offer is the only door to these tools now, so a bare
     // name is not enough — and the hint arrives while you are still choosing.
+    // BOUND TO THE VERB ID RANGE, NOT THE WHOLE MENU. These two used to be unfiltered, and
+    // wxWidgets pushes dynamic entries to the FRONT of the handler list, so being bound LAST made
+    // them run FIRST for every id — including the mate rows at mate_base+1 (base+501) above. Both
+    // fall out of `bound`'s range there and return WITHOUT e.Skip(), which wx reads as "handled",
+    // so the mate handlers never ran: hovering a mate kind showed no ghost and left the previous
+    // status message on screen, and clicking one created nothing at all. The whole mate palette
+    // enumerated perfectly and fired nothing. Restricting the range keeps each half to its own ids
+    // regardless of bind order.
     menu.Bind(wxEVT_MENU_HIGHLIGHT, [this, &bound, base](wxMenuEvent& e) {
         const int i = e.GetMenuId() - base;
         if (i < 0 || i >= int(bound.size()) || bound[i] == nullptr || bound[i]->hint == nullptr)
@@ -5793,12 +5801,12 @@ void DesignPanel::show_offer_menu(const wxPoint& screen_pos)
         m_status->SetForegroundColour(wxNullColour);
         set_status(wxGetTranslation(wxString::FromUTF8(bound[i]->hint)));
         m_status->Update();   // the popup owns the loop; without this the line repaints late
-    });
+    }, base, base + 499);   // 499: the mate section starts at base + 500 (see mate_base)
     menu.Bind(wxEVT_MENU, [this, &bound, base](wxCommandEvent& e) {
         const int i = e.GetId() - base;
         if (i >= 0 && i < int(bound.size()) && bound[i])
             run_offer_action(bound[i]->action);
-    });
+    }, base, base + 499);   // 499: the mate section starts at base + 500 (see mate_base)
     PopupMenu(&menu, ScreenToClient(screen_pos));
     // PopupMenu is modal, so by here the menu is gone and any command it raised has already run.
     // A hover ghost that outlived the menu it belonged to would leave the committed bodies hidden