waylandbridge: destroy frame callbacks on dispatch thread

[Leeestephen]

Summary

Destroy delivered wl_callback resources on the client dispatch thread instead of the
render thread.

This avoids a race between wl_resource_destroy() mutating the client’s Wayland object
map and the dispatch thread creating the next frame callback with a newly reusable
object ID.

Problem

awl_surface_presented() runs on the render thread. It previously performed all three
operations there:

1. Send wl_callback.done.
2. Remove the callback from the surface list.
3. Destroy the callback resource.

Meanwhile, the client dispatch thread can process another wl_surface.frame request
and create a new callback. Destroying the old resource concurrently with that
allocation can corrupt or confuse the client object map.

During physical drag-and-drop testing, this produced a protocol error such as:

Wayland protocol error: interface 'wl_callback' has no event 5

Change

The render thread now:

• Sends wl_callback.done.
• Marks the callback as delivered.
• Leaves the resource parked in the surface callback list.

On the client’s next wl_surface.frame request, surface_frame() destroys delivered
callbacks before creating the replacement callback. This keeps object-map mutation on
the dispatch thread.

Callbacks are also reclaimed during normal surface teardown if the client does not
request another frame.

Why the deferred destruction is safe

The callback remains alive briefly after done is sent, so its object ID cannot be
reused until the server destroys it and emits delete_id.

Destroying delivered callbacks before creating the next callback keeps the parked set
bounded under the normal frame-request cycle.

The existing recursive per-surface ev_lock allows the resource-destruction listener to
remove the callback from the list while surface_frame() performs this cleanup.

Testing

• The Android waylandbridge native target builds successfully against current upstream main.
• The original callback corruption was reproduced while testing physical native-Wayland drag-and-drop.
• A locally installed Anland 6.2 daemon containing this fix completed repeated LibreWolf drag-and-drop tests without reproducing the wl_callback protocol error.
• The daemon remained operational after an Android reboot and cold container start.

The runtime build also contained the separate DnD event-ordering fix; this PR contains
only the frame-callback lifecycle change.

Scope

This does not move wl_callback.done delivery back to the dispatch thread. Cross-thread
event sending remains handled by Anland’s patched libwayland synchronization.

The change only moves wl_resource_destroy() and the associated object-map mutation to
the client dispatch thread.