Implement Makepad Event and Action Patterns

Best practices for event handling and action patterns in Makepad applications, drawn from the Robrix (Matrix chat client) and Moly (AI chat application) codebases. Covers defining domain-specific action enums, with a required None variant via DefaultNone, emitting widget actions from a widget's handle_event, and centralizing action handling in the app via the MatchEvent trait.

Use this when implementing custom actions in Makepad, handling events in widgets, centralizing action handling in App, or widget-to-widget communication - matched by keywords like makepad action, makepad event, widget action, handle_actions, cx.widget_action.

Not needed for non-Makepad Rust UI work, or for simple widgets with no cross-widget communication needs.

Defines a domain-specific action enum, such as MessageAction with React/Reply/Edit/Delete/OpenContextMenu variants plus a required None variant, and emits it from a widget's hit-testing logic via cx.widget_action(self.widget_uid(), &scope.path, MessageAction::Reply(...)). Distinguishes three action kinds: Widget Actions, emitted by widgets and handled same-frame, cast via action.as_widget_action().cast() and optionally matched against a specific widget UID; Posted Actions, posted from async tasks via Cx::post_action plus SignalToUI::set_ui_signal() to wake the UI thread, handled via downcast_ref rather than the widget-action path; and Global Actions for app-wide state changes via cx.action(...), also handled via downcast_ref.

cx.widget_action(
    self.widget_uid(),
    &scope.path,
    MessageAction::Reply(self.get_details()),
);

Centralized handling lives in App's MatchEvent::handle_actions, which loops over actions applying four patterns - direct downcast_ref for non-widget actions, as_widget_action().cast() for widget actions, downcast_ref matches for other enum variants, and modal-specific action handling - calling continue after each handled action. Also documents hit-testing patterns (FingerDown, FingerUp, FingerMove, FingerHoverIn, FingerHoverOut, FingerScroll), keyboard event handling via Event::KeyDown matched on KeyCode and modifiers, signal events for polling async update queues, and an action-chaining pattern where a child widget's action is caught by its parent and re-emitted with added context. Best practices: every action enum needs a DefaultNone-derived None variant, call continue after handling, use downcast_ref for posted/async actions versus as_widget_action().cast() for widget actions, always call SignalToUI::set_ui_signal() after posting from async, centralize handling in App::handle_actions, and use descriptive action names. Further Moly-specific patterns, including store-based action forwarding, timer-based retry, and platform-conditional actions, are documented in references/moly-action-patterns.md, with additional Robrix-specific action and event-handling reference material in references/action-patterns.md and references/event-handling.md.

Rust developers building Makepad UI applications, especially ones following the Robrix/Moly architecture, who need concrete action-definition, emission, and centralized-handling patterns instead of working these conventions out from scratch.