v0.33.0

What changed and why

One public API addition makes this a minor release: ViOverlayItem.StrokeScale, a per-item line-width multiplier. A consumer
asked to draw one NG box bolder so it can be seen from a distance on an operator monitor. Until now no overlay line width could be
changed. In CvDispCtrl every segment and rect was 2 and every polyline 1.2 device-independent pixels, fixed on screen.

The release also adds side handles to editable rects in CvDispCtrl. Grabbing the middle of a side moves only that side, rotated
rects included. This is an interaction change with no API.

Take this release if you want one overlay item drawn bolder (or thinner) than the rest, or want teaching rects resizable by one
side.

Upgrading from 0.32.0:

• Nothing to change: the default StrokeScale is 1.0 and draws as before. One visible difference: CvDispCtrl now draws a
  ViOverlayRect as one closed outline, so its outer corners are filled. At the default width a 1×1 pixel at each corner used to
  stay empty.
• Code that sets StrokeScale will not compile against 0.32.x.
• If you render overlays yourself (to an image for history, for example), read StrokeScale there too, or the bold item will
  look bold on screen only.

Core — ViOverlayItem.StrokeScale (new API)

double, init-only, default 1.0. It multiplies the renderer's base line width. It applies to segments, rects and polylines.
Labels ignore it; text size is FontSize (and CvDispCtrl.OverlayLabelScale). The copy constructors carry it, and so does
ViOverlay.CropTo. Zero, negative, NaN and infinity draw as 1.0. They do not throw, because overlays are built while an
inspection runs, and an exception there would kill the verdict.

Wpf — CvDispCtrl draws the multiplier

• The width stays screen-fixed: the base width (2 for segments and rects, 1.2 for polylines) times StrokeScale, independent of
  zoom. With the tests' layout, a segment at 1.0 covers 3 screen pixels including antialiasing, and about three times that at 3.0.
  At half the zoom the screen width is the same.
• A segment's end arrow grows by the same factor. If the arrow would be longer than the segment, it is shrunk to the segment's
  length, so a bold arrow on a short segment no longer sticks out behind the start point.
• Values are clamped to 0.25–50. A vanishingly small positive value would otherwise erase the line, while 0 is drawn as 1.0. A
  huge finite value would overflow to an infinite pen and NaN arrow points.
• A rect is drawn as one closed outline. With four separate lines and flat ends, the outer corner squares stayed empty, which at
  3× left a visible 3×3 notch at each corner of the bold box.

Wpf — side handles on editable rects

A resizable CvEditRect in Shapes now has a handle in the middle of each side, drawn as a slightly thicker solid stretch over
the dashed outline. It is 5 device-independent px wide and one third of the side long, capped at 24, so on a large rect only the
middle of each side looks a bit thicker.

• Dragging it moves that side only, by the distance dragged. The opposite side stays put, and the other axis keeps its size and
  place.
• The drag works in the rect's own frame, so a rotated rect keeps its angle and grows only along its own axis. Movement across
  that axis is ignored.
• Priority: every shape's corner and rotation handles come first. A side handle then loses to the body of a smaller shape under
  the pointer, so a search box tightly around a train box no longer takes a press meant to move the train box. Of two sides in
  reach (a thin strip), the nearer one is taken.
• A side handle is left out when the side is shorter than 21 device-independent px on screen, or when its middle lies within a
  corner handle's reach. A handle that cannot be grabbed is not drawn. Fixed-size rects (IsResizable = false) have none.

What you may notice: a press near the middle of a rect side that used to move the rect (inside it), or do nothing (outside
it), now resizes that side.

To test this without a mouse, the surface's press, drag and release handling was split into internal methods that take
coordinates. The mouse handlers call them, and CvInspect.Wpf.Tests gets InternalsVisibleTo. The public API does not change.

Documentation

The Overlay row of the CvInspect.Wpf README states the base widths, that they are screen-fixed, and how StrokeScale applies.

Tests

The WPF suite grows from 57 to 60; the core suite stays at 140. Two of the new WPF tests drive the side handles through the
coordinate-based press, drag and release. They cover each of the four sides with off-axis wobble, a 30° rect (angle and opposite
side kept), corner priority, a fixed-size rect, the length floor, nested search and train boxes, a thin strip, a press inside the
grab band, and the drawn thickness and its cap. Eight mutations, one per rule, each turned them red. A consumer then checked it
with a real mouse on its teaching screens: one- and two-axis drags, a rotated train region, and a train box inside a tight search
box. For the overlay stroke, the core suite stays at 140, because the existing reflection test of the copy constructors
picked up the new property without being edited (and fails if a copy drops it). StrokeScaleThickensOneItemAtAnyZoom covers
segments, rects and polylines separately, at 3× and at both ends of the clamp, with an upper bound so that applying the factor
twice fails. It also checks the four invalid values on lines and arrows, the same screen width at half the zoom, the arrow size,
the short-segment arrow, the four outer corners of a bold rect, and CropTo. Six mutations each turned a test red: dropping the
copy, ignoring the factor for polylines, a fixed arrow, no invalid-value guard, four separate rect lines, and no arrow shrink.

Version

0.33.0 — minor. Public API was added: ViOverlayItem.StrokeScale. The patch exception for completing the previous minor's
feature does not apply.

Checks

• dotnet build CvInspect.sln -c Release --no-incremental reports 0 warnings (an incremental build reports none when it recompiles nothing)
• main is an ancestor of this branch (the release-pr-guard job verifies it)
• the tag will be created on the merge commit, main merged back into dev afterwards, and dev bumped to the next -dev version