Add PLUM ecoNEXT Gateway integration

[wsjoanna222]

What changed

• add the local fuxa-plugin-plum-econext-gateway device integration
• register plugin id plum-econext-gateway with display name PLUM ecoNEXT Gateway
• support browse, grouped parameter discovery, polling, reads and validated writes
• map ecoNEXT OpenAPI protocol types to FUXA tag types
• add a dedicated PLUM tag-property editor with index/name search, numeric sorting and write feedback
• add translations for PLUM ecoNEXT Gateway and HTTP timeout
• support local plugin discovery and cover Windows junction behavior

Why

This integrates FUXA with the local REST API exposed by LeeNuss/econext-gateway for PLUM ecoMAX controllers. The implementation keeps gateway parameter names and indices visible while allowing a FUXA-only tag alias.

Validation

• backend TypeScript build: passed
• server tests: 99 passing, 1 pending (Linux symlink test skipped on Windows)
• frontend production build: passed
• physical ecoMAX 360i: browse/read/write and polling confirmed; panel service writes require the corresponding gateway fix in LeeNuss/econext-gateway PR Authentication & Authorization #10

Device testing still recommended

• long-running polling and reconnect behavior
• firmware variants and complete parameter/type coverage
• Raspberry Pi deployment and Linux symlink discovery
• min/max and read-only enforcement across the full physical parameter set

[unocelli]

Hi @wsjoanna222 Thanks for the contribution. The PLUM ecoNEXT integration looks useful, especially because the last commit moves it toward an optional plugin instead of a mandatory server dependency.

I think FUXA can support vendor-specific integrations through the plugin system, but we should avoid adding a dedicated core/client path for every vendor device family. PLUM ecoNEXT is different from Modbus, OPC UA, MQTT or BACnet: it is not a general industrial standard, it is an adapter for the PLUM ecoNET/ecoNEXT ecosystem.

So before merging, I would suggest aligning this PR with a more generic plugin architecture.

Suggested direction:

• keep the PLUM driver under server/integrations/plum-econext-gateway;
• keep it installable only through the Plugin Manager;
• keep all PLUM-specific REST API logic, /api/parameters, type mapping, writable/range validation, etc. inside the plugin;
• make connection-device plugins dynamically registered/loaded by type, instead of adding one hardcoded branch per vendor in server/runtime/devices/device.js;
• avoid adding a dedicated Angular component for PLUM if possible;
• expose generic plugin metadata for device connection properties and browse/tag creation;
• reuse or introduce a generic plugin tag browser based on the plugin browse() response.

There is also a blocking test issue: server/test/devices/plumEconextGateway.test.js imports Chai with require('chai'), but this repo uses Chai as ESM. This prevents Mocha from loading the test suite, even when running unrelated --grep tests. It should follow the existing test pattern using await import('chai').

As an incremental path, I would suggest:

1. Fix the Chai import so the test suite loads again.
2. Keep the PLUM runtime driver and optional installation.
3. Refactor the device plugin loading to be generic for connection-device plugins.
4. Either reuse an existing generic browse/tag UI or split the PLUM-specific UI work into a follow-up after the plugin metadata shape is agreed.

If you agree with this direction, I can push a small commit to this PR branch with the Chai test fix and an initial generic connection-device plugin loading refactor, so you can review whether it matches your integration needs before we go further on the UI side.