vkcube: doesnt respect xdg_toplevel configure

it seems vkcube disregards the xdg_toplevel configure of the new size and just proceeds with the size 500,500 buffer and eventually hits renderpassbegin with a renderarea larger then the buffer itself. shouldnt vkcube in this case either restrict itself to the buffer or simply make a new one?

```
[3632565.283] -> wp_tearing_control_v1#36.set_presentation_hint(0)
[3632566.003] -> zwp_linux_dmabuf_v1#43.create_params(new id zwp_linux_buffer_params_v1#44)
[3632566.007] -> zwp_linux_buffer_params_v1#44.add(fd 37, 0, 0, 2048, 50331648, 14712852)
[3632566.009] -> zwp_linux_buffer_params_v1#44.create_immed(new id wl_buffer#30, 500, 500, 875709016, 0)
[3632566.012] -> zwp_linux_buffer_params_v1#44.destroy()
[3632566.017] -> wp_linux_drm_syncobj_manager_v1#40.import_timeline(new id wp_linux_drm_syncobj_timeline_v1#45, fd 39)
[3632566.549] -> zwp_linux_dmabuf_v1#43.create_params(new id zwp_linux_buffer_params_v1#46)
[3632566.551] -> zwp_linux_buffer_params_v1#46.add(fd 42, 0, 0, 2048, 50331648, 14712852)
[3632566.553] -> zwp_linux_buffer_params_v1#46.create_immed(new id wl_buffer#47, 500, 500, 875709016, 0)
[3632566.554] -> zwp_linux_buffer_params_v1#46.destroy()
[3632566.557] -> wp_linux_drm_syncobj_manager_v1#40.import_timeline(new id wp_linux_drm_syncobj_timeline_v1#48, fd 44)
[3632566.973] -> zwp_linux_dmabuf_v1#43.create_params(new id zwp_linux_buffer_params_v1#49)
[3632566.975] -> zwp_linux_buffer_params_v1#49.add(fd 47, 0, 0, 2048, 50331648, 14712852)
[3632566.977] -> zwp_linux_buffer_params_v1#49.create_immed(new id wl_buffer#50, 500, 500, 875709016, 0)
[3632566.979] -> zwp_linux_buffer_params_v1#49.destroy()
[3632566.981] -> wp_linux_drm_syncobj_manager_v1#40.import_timeline(new id wp_linux_drm_syncobj_timeline_v1#51, fd 49)
[3632567.164] {Default Queue} wl_seat#4.capabilities(3)
[3632567.167] {Default Queue} -> wl_seat#4.get_pointer(new id wl_pointer#52)
[3632567.169] {Default Queue} -> wl_seat#4.get_keyboard(new id wl_keyboard#53)
[3632567.170] {Default Queue} discarded zxdg_toplevel_decoration_v1#10.configure(2)
[3632567.172] {Default Queue} discarded zxdg_toplevel_decoration_v1#10.configure(2)
[3632567.178] {Default Queue} xdg_toplevel#9.configure(1280, 701, array[0])
[3632567.182] {Default Queue} xdg_surface#8.configure(252)
[3632567.183] {Default Queue} -> xdg_surface#8.ack_configure(252)
Validation Error: [ VUID-VkRenderPassBeginInfo-pNext-02852 ] | MessageID = 0xdb2c5767
vkCmdBeginRenderPass(): pRenderPassBegin->renderArea offset.x (0) + extent.width (1280) is greater than framebuffer width (500).
The Vulkan spec states: If the pNext chain does not contain VkDeviceGroupRenderPassBeginInfo or its deviceRenderAreaCount member is equal to 0, renderArea.offset.x + renderArea.extent.width must be less than or equal to VkFramebufferCreateInfo::width the framebuffer was created with (https://docs.vulkan.org/spec/latest/chapters/renderpass.html#VUID-VkRenderPassBeginInfo-pNext-02852)
Objects: 2
[0] VkRenderPass 0xd000000000d
[1] VkFramebuffer 0x270000000027
```

Start at the vkcube entry point that handles the Wayland xdg_toplevel configure and compare its acknowledged size with the 500x500 framebuffer shown in the trace. Reproduce the validation error, then ensure the chosen window or buffer dimensions stay consistent with the configure event and verify that render-pass begin no longer exceeds the framebuffer.

Written by the indexing model from the issue text.