Add runtime Moonraker capability discovery and event subscriptions

[swcrazyfan]

Problem

The current Moonraker provider relies on periodic HTTP status queries and assumes a fixed core object set. Klipper installations expose different heaters, fans, lights, commands, and vendor modules, so future provider features need a model-neutral way to discover what a printer actually supports.

Proposed scope

• Discover available Klipper objects through /printer/objects/list
• Discover available G-code handlers through /printer/gcode/help
• Publish a generic runtime capability summary with printer status
• Subscribe to discovered core status objects through Moonraker's /websocket
• Merge partial status notifications and resubscribe after Klippy restarts
• Reconnect with bounded backoff while retaining HTTP polling as a fallback
• Provide an object-subscription extension point for later provider-specific adapters

This issue intentionally excludes QIDI-specific objects, proxying, print queues, Spoolman reconciliation, and new printer-control UI.

Validation completed locally

• Focused Moonraker/provider regressions: 185 passed
• Full backend suite: 5,279 passed
• Ruff check and format check
• Production Docker image build and health smoke
• Read-only validation against a live Moonraker/Klipper printer, including passive WebSocket status updates

I have a focused implementation branch ready and would like to be assigned before opening the draft PR, per the contribution workflow.