feat(ffi): add processing_poll_events for external event loop integration - #237

Summary

Adds processing_poll_events() to the C FFI, which ticks Bevy's app one frame. This lets embedders that manage their own window and event loop advance libprocessing's internal state each frame without using the built-in runner.

Motivation

When embedding libprocessing into a native host that drives its own event loop, there is no way to tick the Bevy app from outside. The Python bindings have poll_events() on the Surface struct but this is not exposed over C.

The window system the host uses does not matter. The host creates a WebGPU surface via processing_surface_create, passes native window and display handles, and drives the frame loop itself. processing_poll_events is what advances Bevy's ECS and render world each frame in that model.

Usage

processing_init();
uint64_t surface = processing_surface_create_x11(window, display, w, h, scale);
uint64_t gfx = processing_graphics_create(surface, w, h);

while (running) {
    running = processing_poll_events();
    processing_begin_draw(gfx);
    // draw calls
    processing_end_draw(gfx);
}

Changes

• Add processing_poll_events() -> bool to processing_ffi/src/lib.rs
• Add processing_core as a direct dependency of processing_ffi since app_mut is not re-exported through processing::prelude

Notes

This builds on top of #236 since that fix is required for the crate to compile on Linux.