Accessibility infrastructure for the client UI (AccessKit exploration)

Nobody has claimed this yet.

Related to #14041, but this is about the engine UI rather than only a TTS API for mods.

I am blind and use a screen reader daily. I also work as a developer, mostly with Python and Flutter, with some C/C++ experience. I am interested in working on accessibility in Luanti myself.

A TTS API for mods would still be useful for gameplay feedback, alerts, or world exploration. However, it would not make the client UI accessible on its own. Menus, formspecs, inventories, settings, and dialogs need to be exposed as actual accessibility controls so that screen readers can navigate them normally and present them through speech or braille.

I am currently looking into AccessKit as a possible way to do this. My understanding is that Luanti's custom-drawn UI would need to be represented as an accessibility tree and exposed to the operating system, rather than having the engine manually speak every piece of text.

My eventual goal would be to make as much of the client UI as possible accessible. For a first prototype, I would probably start with simpler controls in the main menu and formspecs, then see how far the same approach can be extended to inventories, settings, and other UI.

Before spending a lot of time on it, I would like to know whether maintainers would be open to reviewing an upstreamable implementation in this direction.

In particular:

* Would an AccessKit-based integration be an acceptable direction for the project?
* Is there an existing UI abstraction or planned work that I should build on instead?
* Are there concerns about supported platforms, dependencies, or the current Irrlicht GUI that I should consider from the beginning?

I have not implemented an integration like this before, so I cannot promise a result yet. But I am willing to investigate it, build a small prototype, and submit incremental PRs if there is interest.

Start with the main menu and formspec controls, then investigate how the custom-drawn client UI could be represented through AccessKit and exposed to screen readers. Check whether an existing UI abstraction or planned work should be used, and identify platform and dependency constraints. Done would be a reviewed, upstreamable prototype with a path to extending accessibility to inventories, settings, and dialogs.

Written by the indexing model from the issue text.