Implement Lua-native multi-window addons

Implement a Lua-first mechanism for external UI packages to declare and expose multiple windows without replacing a built-in provider role. Intended outcome: - External packages can register multiple custom XML/Lua windows with independent lifecycle, persistence and diagnostics. - The Control Center can present discovered addon windows without addon-specific C# registration. - Native code remains a narrow authority/lifecycle substrate; composition and presentation stay in Lua. Constraints: - Preserve package isolation, bounded manifests/assets and opaque window references. - Do not introduce cross-package Lua calls or let addons discover unrelated native windows. - Keep physical input provenance and combat lockdown rules intact. - Avoid fixed enum slots or addon-specific C# classes. Design conclusion: - Treat an external package with no `<Provides>` entries as a standalone addon package. Lua explicitly registers each owned window frame with a package-local key and launcher label; the full stable destination is namespaced by package id. - Load each standalone package in its own existing Lua VM with generic widget, preference, diagnostics and permitted observation services, but no typed game-command capability and no window-directory access. - Use a neutral package root and require every exposed child to be a declared Lua window frame. Register each through a generic dynamic-window path with character-scoped layout identity derived from package id and local window key. - Pass only the discovered addon destination keys and labels to the Control Center component. The bundled Control Center Lua builds an Addons submenu with `ui.windows.require` and `ui.menu.window`; addon packages do not discover or call one another. - Refactor native window bookkeeping to support dynamic handles rather than reserving enum slots. Keep C# limited to discovery, isolation, lifecycle, persistence and opaque destination grants. - Support multiple windows from the first version. Launcher icons/categories and slash-command aliases remain future extensions. - Discover packages from both `<client>/UI/Addons` and the per-user `ProjectRubiKa/ui-packages` directory as one catalog; duplicate package ids across either location are refused. - Ship Combat Meter under `UI/Examples/CombatMeter` as a non-official installable addon rather than a built-in provider. Pull request: #2964 https://git.project-rk.com/prk/engines/pulls/2964