Design: the offer ships — right-click the geometry, get what applies to it

Row order is RATIFIED (charter 4.1, 2026-07-31) and this is the first working
implementation of it: right-click in the Design viewport and a vertical list
opens at the pointer with the eight families in their fixed order, the verbs
that apply live, and the ones that do not disabled IN PLACE carrying their
reason.

THE MAP EXISTS ONCE. DesignOffer.hpp is GENERATED from docs/ux/tool_atlas.json
by docs/ux/mockups/gen_offer_table.py — the same file the 113 mockups are drawn
from. A drawing and the product therefore cannot drift apart, which is the only
way row constancy survives contact with a codebase. Never hand-edit the header.

NOTHING IS RE-IMPLEMENTED. Each row routes to the code that already runs that
verb: "key:S+E" through m_keys_feature, "key:L" through m_keys_sketch,
"fly:material#4" through the feature flyout's own action, "btn:colour" through
the standalone button. The offer is a second door onto the same room, so the
toolbar, the shortcuts and the menu cannot drift into three behaviours. The 8
verbs with kernel support but no GUI path show disabled, which is honest and
matches section 10 of the charter.

Right-click only fires the offer when the canvas is IDLE. Right-click already
ends a polyline chain and finishes the move gizmo; taking those over would
break two working interactions to add a third.

Two things the running build corrected, both found by looking at screenshots:

- THE REASON MUST BE TRUE FOR WHAT IS IN FRONT OF THE USER. Taking the first
  refusal in a family printed "Transform needs a body — add or import one
  first" on a document that HAS a body, because the real obstacle was that
  nothing was selected. Now the reason comes from a verb that accepts the
  current selection and fails only on document state; if no verb in the family
  accepts this selection at all, it says "select something first" or says
  nothing. A menu whose whole value is telling the truth cannot ship a lie.
- Classification follows the level the pick cycle has REACHED, not the face the
  ray happened to hit, so the header cannot name a face while the whole body is
  lit. Sketching on the face you merely clicked is untouched — that path is
  sketch_plane_from_selection (snaporca-3a2).

Verified on :11 end to end: nothing selected shows Sketch live with Shift+S and
seven greyed rows each explaining itself; a selected solid shows Move directly
with Shift+Y (one applicable verb, so no submenu and no extra click) and five
families as submenus. Both forks compile and link.

Fork parity re-checked after the port: DesignPanel.cpp 30 divergent lines,
DesignCanvas.cpp 16, every other CAD file byte-identical — the invariant exactly.

snaporca-96r.

src/slic3r/GUI/DesignPanel.hpp

@@ -602,6 +602,15 @@ private:
     // What the live sketch was actually opened on ("the picked face", "XY", a datum's name), so the
     // hint can say it. Resolved from the selection at begin_sketch, not read back from a combo.
     wxString          m_sketch_on;
+    // --- the object-driven offer (charter 4.1) ---------------------------------------------
+    // Right-click the geometry -> a vertical list in ratified row order, verbs that do not
+    // apply disabled IN PLACE with their reason. The rows come from the generated table in
+    // DesignOffer.hpp; this map is how a row reaches the code that already implements it, for
+    // the verbs that have no keyboard shortcut to route through.
+    std::map<std::string, std::function<void()>> m_verb_actions;
+    void show_offer_menu(const wxPoint& screen_pos);
+    int  offer_selection_kind() const;          // an OfferSel, as int to keep the header light
+    void run_offer_action(const char* action);
     // Face-as-profile extrude (Onshape): when Extrude is opened on a picked solid face with
     // no sketch source, this carries that global face id so the kernel extrudes the face.
     // -1 = ordinary sketch/loop extrude. Set when opening the Extrude card, consumed on add.