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

## 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:

```ts
// 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