Design: clicking the same face twice takes the body, and the status line moves onto the viewport

A click could point at a face, an edge or a vertex, but never at the body those
belong to: offer_selection_kind() can only return BodySolid when all three are
clear, which a viewport click never produces. The rubber band was the only door,
and the status line said "face 5 selected" while the user believed they had taken
the body. A second click on the SAME sub-element now escalates to it (snaporca-gem).

Not the pick cycle that was removed in bc2b741ce9 -- that one was silent and three
deep, so no click had a predictable meaning. Here the status line names the next
click before you make it, and a further click just takes the face under the cursor
again, which needs no teaching. Double-click is untouched: wx sends Down/Up/DClick/Up
and only the first Up carries a pending press, so a fast double-click still zooms to
fit and picks once.

The status line itself moved to the base of the viewport. In the side panel it was
clipped at ~73 characters with no warning and no wrap -- set_status()'s Wrap() never
took effect (snaporca-8cc) -- which silently length-limited every hint in the tab; the
first version of this change lost a clause to it. m_status is kept, hidden, as the
owner of the text and its colour, and the line is drawn in a bottom-left twin of the
readout HUD where there is a whole window's width.

Three defects found driving it on the rig, none of which the build could see:

  * the HUD as a wxFrame took the WM's keyboard focus every time it was raised, and
    the canvas then received NO key events -- every sketch shortcut silently dead.
    Caught with SNAPORCA_KEYTRACE: shift+S logged a line, the following R logged
    nothing. It is a wxPopupWindow now, which cannot be focused. SetFocus() on the
    canvas does not fix it: focus was on another toplevel.
  * zero vertical padding fits the popup tighter than the font's line box and clips
    the glyphs; 6 (what the readout uses) reads as a two-line box. 3 is right.
  * "has a caller chosen a colour?" compared the label's foreground against its
    PARENT's, which differ by default, so every line counted as chosen and the
    neutral text came out the panel's dark grey -- invisible on a dark chip. Compare
    against the colour the label was created with, captured before any caller writes.

Verified on both rigs against fresh binaries: sketch -> extrude -> click face ->
click again -> whole body tinted, offer opens with the body rows live and Create /
Add material correctly greyed. Keyboard drives the whole sequence.

Filed and NOT fixed here: snaporca-od0 -- a bare-plate click does not deselect the
solid, so "click away, click back" escalates. Pre-existing; clearing there would also
drop the face the Thicken/Shell/Draft cards hold, which needs its own pass.

Refs: snaporca-gem, snaporca-8cc, snaporca-od0

src/slic3r/GUI/DesignPanel.hpp

@@ -779,6 +779,10 @@ private:
     static int tree_icon_for(CadFeatureType t);
 
     wxStaticText*     m_status{nullptr};
+    // m_status's foreground as created, captured before any caller touches it. Callers signal
+    // "no opinion" by setting wxNullColour, which restores exactly this — so it is the only
+    // reliable way to tell a chosen colour (the error red) from the default. See set_status().
+    wxColour          m_status_default_fg;
     wxStaticText*     m_dof_status{nullptr};   // DoF / constraint-state readout (P3)
     int               m_feature_counter{0};