in android gesture system is not reporting GESTURE_NONE, specified in the issue https://github.com/raysan5/raylib/issues/5010 so, automatically GESTURE_SWIPE, TAP, DOUBLE_TAP, also will not be reported. in this commit it is fixed.

* Add chicken scheme to BINDINGS.md

* Fix typo

It does not work as expected... :(

Considering multi-monitor and multi-ppi configurations
Fullscreen-exclusive scales to available display resolution, ignoring content scaling
Windowed-borderless scales to available logical resolution considering HighDPI **if requested**

Kept only for platforms that could potentially need it

- Changed GLTF_ANIMDELAY (17ms, ~58.82fps) to GLTF_FRAMERATE (60.0fps)
- Updated frameCount calculation: (animDuration * 60) instead of (animDuration * 1000 / 17)
- Updated time calculation: j / 60.0f instead of (j * 17) / 1000.0f

This fixes animation frame count misalignment when importing glTF models
exported at standard 60fps. Animations that were 27+ frames shorter than
expected on 1350-frame sequences will now import correctly.

* fix: set correct default axes for gamepads that are not connected

`glfwGetGamepadState` will set all gamepad state variables to 0.0 if required gamepad is not connected, but `RecordAutomationEvent()` inside rcore.c expects trigger axes to be -1.0f when gamepad is not connected. Since SDL and RGFW return -1.0f in such case, this change is aligning it with them

* updated comment in rcore_desktop_glfw.c

* [rcore][android] Fix keyboard input detected as gamepad on some devices (#5387)

* [core] Add keyboard vs gamepad input test example (#5387)

Note that issue has been reported by CodeQL static analysis system

* Possibly fixed the swizzling bug

* Removed examples, and generation.

Tested on two monitors with different DPI configuration, for HigDPI enabled and not, including window resizing (with framebuffer resizing if required). Verified mouse coordinates follow the requested screen size.

Note that high-dpi awareness must be enabled by users and `CORE.Window.render` reports the scaled framebuffer size, while `CORE.Window.screen` reports the logical size.

`ToggleBorderlessWindow()` has also been reviewed to be consistent with scaling, if monitor physical display size is reported as 1920x1080 but there is a content scale of 1.5, then the borderless fullscreen window will be 1280x720, with the 1920x1080 framebuffer