Unified input device abstraction (DeviceSourceManager subset) for keyboard, mouse, touch, gamepad #410

Summary

Request a minimal input abstraction in Babylon Lite, or an official recommended pattern, to replace @babylonjs/core DeviceSourceManager for games that read keyboard, mouse, touch, and gamepad state each frame outside of built-in camera controllers.

The device managing/controller input is also possible to be implemented outside of Babylon Lite, but it would be nice to know if this is the plan!

Motivation (real-world port)

Our game client uses DeviceSourceManager to unify input across devices:

// Current BJS usage (simplified)
const dsm = new DeviceSourceManager(engine)

const keyboard = dsm.getDeviceSource(DeviceType.Keyboard)
const mouse = dsm.getDeviceSource(DeviceType.Mouse)
const gamepad = dsm.getDeviceSource(DeviceType.Switch) // Nintendo-style mapping

// Per frame:
keyboard.getInput(Keys.W)
mouse.getInput(PointerInput.MovementX)
gamepad.getInput(SwitchInput.LStickXAxis)
gamepad.getInput(SwitchInput.A)

This feeds a custom ECS input system (movement, interact, aim, weapon swap) — not camera attachControl only.

Camera control is separate (ArcRotateCamera.attachControl); we still need raw device polling for gameplay.

Proposed scope

Must have

• Keyboard: key down/up or polled state for common keys
• Mouse: movement deltas, buttons, wheel
• Pointer/touch: primary pointer position (for UI + world projection)
• Gamepad: at least one connected pad, axes + buttons (standard or configurable mapping)

Nice to have

• onDeviceConnectedObservable / onDeviceDisconnectedObservable
• Multiple gamepads
• DeviceType enum compatible with @babylonjs/lite-compat

Out of scope

• Action mapping / rebinding UI
• Full CameraInputManager port
• XR controllers

Design preferences (Lite-aligned)

• Prefer standalone functions over classes where possible (pollKeyboard(), pollGamepad(index))
• Zero module-level side effects; tree-shakable per device family
• No dependency on @babylonjs/gui or scene graph

Acceptance criteria

• Example in lab: read WASD + mouse look + gamepad stick in a render loop
• Works alongside existing camera control helpers (don't conflict with attachArcRotateControls)
• Documented migration from DeviceSourceManager
• Optional @babylonjs/lite-compat shim exposing DeviceSourceManager over Lite APIs

Alternatives considered

• Raw DOM (keydown, pointermove, navigator.getGamepads()) — viable but we'd lose cross-app consistency and any future Babylon Native parity
• Only camera-bound input — insufficient for action games