backend/wayland/vulkan: Fix use of Vulkan (correctly this time)

[ids1024]

It seems #280 was just wrong. I didn't test it correctly, and it actually prevented crashes simply because the Vulkan instance failed to create.

This failed because it's a device extension, not an instance extension (and we already check for the device extension).

The real issue seems to be simply the fact this was using the Instance after dropping the Entry. Which is easy enough to address.

• I have disclosed use of any AI generated code in my commit messages.
  • If you are using an LLM, and do not fully understand the changes it is making to the code base, do not create a PR.
  • In our experience, AI generated code often results in overly complex code that lacks enough context for a proper fix or feature inclusion. This results in considerably longer code reviews. Due to this, AI authored or partially authored PRs may be closed without comment.
• I understand these changes in full and will be able to respond to review comments.
• My change is accurately described in the commit message.
• My contribution is tested and working as described.
• I have read the Developer Certificate of Origin and certify my contribution under its conditions.

[ids1024]

The calloop change is probably good, but it's hard to test when there are other issues that are inconsistent and could look similar to and issue with that change. And it's not important. So I'll split that off into a draft: #293 (maybe combined with other fixes later).

[ids1024]

This should be tested on a Meteor Lake system to make sure the workaround this is for is actually working to prevent graphical corruption (though RUST_LOG=info should also show if it failed to initialize Vulkan). And it may as well be tested together with pop-os/cosmic-comp#2185 to make sure Meteor Lake SHM capture is still working properly with both changes.

[leviport]

Seems good on MTL darp10, as well as oryp13