Story: publish an official Flatpak distribution

[inayayousfi]

Problem

There is no cross-distro GUI package story yet beyond the standalone Linux ZIP.

Flatpak could provide a more standard desktop-app distribution path across Linux distributions, especially for users who are not on Arch or Fedora-specific repos.

Scope

Evaluate and, if appropriate, implement an official Flatpak distribution for Axidev OSK.

This should include runtime choice, permissions, sandbox tradeoffs, and publication strategy.

Packaging and runtime architecture context

Axidev OSK is currently shipped as a Python desktop application with a native input stack underneath it, not as a single self-contained native codebase.

Relevant packaging/runtime facts for this story:

• the top-level app package is axidev-osk, a Python package with the CLI entrypoint axidev-osk = axidev_osk.app:main
• the UI/runtime is primarily Python plus PySide6
• keyboard/input integration is not pure Python: the app depends on the vendored axidev-io-python package, which wraps native axidev-io C sources
• on Windows, that native layer uses normal Python extension tooling and Win32 libraries
• on Linux, the native layer depends on system libinput, libudev, and xkbcommon, and those are intentionally expected to remain dynamically linked from the host system
• Linux input features also depend on host permissions such as /dev/uinput access and relevant /dev/input/event* access
• current standalone release artifacts are built with scripts/build_standalone.py, which uses PyInstaller to bundle the Python runtime, the app package, and the Python/native dependency stack into a ZIP archive
• the current release flow publishes standalone ZIP artifacts for Windows and Linux, not a native installer/repository format for each platform yet
• licensing/compliance files for the vendored native stack are already carried into the standalone bundle and need to stay accounted for in any new packaging path

This issue should evaluate trade-offs against that runtime architecture explicitly so someone can reason about the packaging design without first reading the build scripts or code.## Acceptance criteria

• document the current packaging/runtime architecture, including Python runtime, native dependency stack, and artifact shape, so trade-offs can be reviewed without reading the code first
• define whether Flatpak is an official supported distribution target
• create and maintain the Flatpak manifest/build configuration if the answer is yes
• document the permissions and sandbox model required for the app's input and overlay behavior
• choose the publication path (for example Flathub or a project-controlled remote) and document it
• document install and upgrade instructions for users
• ensure the release process can keep the Flatpak package current

Notes

This issue should explicitly call out any limitations Flatpak imposes on input injection, accessibility, overlay behavior, or related desktop integration work.