EventHandler redesign: awaitable semantics

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.

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.

Start by locating the @rx.event registration path, EventHandler, EventProcessor, global event list, and HTTP/OpenAPI endpoint generation described in the issue. Review the roadmap's Section 1b and existing tests around event execution before defining the design. Done means the listed awaitable, partial-argument, context, requeueing, and return-value semantics are implemented and covered by tests.