EventHandler redesign: awaitable semantics #6223

Summary

Redesign @rx.event as the central registration mechanism independent of any state class. Registered events go into a global event list used by the EventProcessor.

Key Changes

• EventHandlers are always awaitable (never generators externally). Generators can be used as the event function, but the external API for calling them is always awaitable.
• Calling an EventHandler applies partial args and returns a new copy. To actually execute, you must await the handler or create a task from it.
• With an EventContext on the stack: execute in-context as a task, return an EventHandler with an active awaitable task.
• Without a context: collect arguments and return an EventHandler with partial args and no task (awaiting is an error).
• Yielded events are requeued on the backend rather than returned to the caller. Internal machinery constructs a delta and sends it to the frontend.
• Return values are sent back in the final delta — eventually allowing event calls to return a promise on the frontend.
• Important: accessing an EventHandler function from a state instance, like self.do_a_thing() continues to work how it does today to avoid breaking existing code as much as possible. The new form would look like await type(self).do_a_thing() — accessing the EventHandler object (through the class) provides the new awaitable object.

Why

The global event registry directly produces the surface for event handlers as HTTP endpoints with OpenAPI spec, enabling agent access and external tool integration. This keeps the __call__ signature consistent while supporting both immediate execution and deferred invocation.

Part of the Reflex Framework Roadmap — Section 1b.