The fix: cursor.position_in(bounds) returns RELATIVE coordinates,
but we were drawing at those relative positions directly.
Solution: Add bounds.x and bounds.y offset when drawing.
- selection.region stores relative coords (from cursor)
- when drawing: absolute = relative + bounds offset
This fixes the Y-position being too far up.
KISS principle: Widget is in stack over canvas, uses SAME coordinates!
- Mouse position = exact position to draw
- selection.region = canvas pixel coordinates
- NO relative/absolute conversion needed
- NO bounds offset calculations
Removed all the over-engineered coordinate math.
Keyboard events (Enter/Escape) are already handled globally in app.rs
subscription and work correctly with Crop mode detection.
Widget-level keyboard events don't work without focus anyway.
Only mouse events (click, drag, double-click) stay in the widget.
B1: Fixed handle positions - now uses relative coordinates correctly
- Handles are drawn at correct positions (relative to bounds)
- Conversion between screen and relative coords
B2: Added Enter and Double-click for Apply
- Enter key applies crop when selection exists
- Escape key cancels crop
- Double-click on selection center applies crop (400ms window)
- CropRegion moved to domain/document/operations/crop.rs (pure model)
- crop_types.rs renamed to crop_model.rs (honest UI model name)
- DragHandle and CropSelection stay in UI layer (where they belong)
- Clean separation: Domain has no UI concerns, UI imports from Domain
