Investigate use of steamrt4 & arm sdk

[d10sfan]

https://gitlab.steamos.cloud/steamrt/steamrt/-/wikis/steamrt4-release-notes

Has newer tooling based on debian 13, so would be good to switch luxtorpeda to use it. Currently, there's quite alot of issues with using the newer stuff, so will need to figure out a way to have both available in parallel, or just freeze the sniper for now.

This would include:

• [ ] Updates to the luxtorpeda client building to build against it
• [ ] Updates to the compatibility tool file to use it instead of sniper
• [ ] Creating a new json file for this so the previous sniper still works and all the updates to handle this
• [ ] PRs to bump all the packages to use steamrt4 (at least the stuff that needs to be built)
• [ ] Handling what to do about qt engines since steamrt4 does not contain qt
• [ ] Release major release for lux client
• [ ] Make sure any 32 bit games still work (and use the scout runtime for the executables)

Engine list to update - TBD

---

There's a ARM SDK in the works - https://github.com/ValveSoftware/steam-runtime/issues/756

See if this makes sense to eventually support here.

Would need to look into the following:

• [ ] client, bullding and providing an arm version, including the godot UI
• [ ] vcpkg, using the right toolset if arm is detected during build, and making sure that the paths for libs and such is correct
• [ ] have the action that gets the sdk image make a matrix of the ubuntu intel and ubuntu arm runners, so the build runs on both (for test and official build)
• [ ] have a armNotSupported flag in packages json that blocks the engine from being launched on that platform in the client, as well as not allowing it to be built (have the matrix be engine name, and the platforms, since some engines will only build on intel)
• [ ] for now, have a whitelist of arm building? eventually should just be "not supported" ones that are blocked
• [ ] have the arm build create a -arm suffix before the .tar* stuff, maybe do that in the package script so all the build scripts don't have to change? then the stuff to add to the runtime should have the normal download and one named x-arm
• [ ] Client changes to support detecting the system type and if arm, looking for downloads with -arm, if it does not find any, assume that the non arm one is ok to load. this will probably break for a bit, but the armnotsupported will handle blocking oens that will never be updated.
• [ ] Look at all of the engines we build, and see what's needed to have them support arm. some may not due to something inside the code, if so, have the armNotSupported flag.
• [ ] is there a translation layer? if so, maybe allow armnotsupported flags through but with a one-time warning?
• [ ] look at all of the binaries we're using and see if there's anything that can be done to support arm. if not add armnotsupported
• [ ] have another icon for this in the packages list
• [ ] feasible hardware to test - gha will handle the building, but what hardware could be used to test all this?