Feature request / maintainership question

### Describe the requested feature I have a need for a flow-based Modbus TCP server for Node-RED, and I have prototyped one by forking this library. The design currently consists of two palette nodes and one config node: - A config node that uses jsmodbus to open and manage a Modbus TCP server on a TCP port - A dynamic-server node that emits incoming requests into the flow - A dynamic-response node that sends the corresponding response The intent is for users to work with friendly Node-RED objects rather than raw protocol request/response frames, in a style similar to flex-getter and flex-writer. Optional per-connection, in-order response handling can also be enforced. I originally chose to fork this project because I assumed users of these nodes would likely also want node-red-contrib-modbus, and I wanted to avoid dependency/version mismatches, especially around jsmodbus. However, after noticing that node-red-contrib-modbus-flex-server was split into its own project, I wanted to ask before going further: **Would a PR adding this functionality to this library be likely to fit the project and be considered for acceptance, or would you prefer that I publish it as a completely separate project?** ### Motivation My main goal is to support smart Modbus gateway and protocol mediation patterns. In this model, a Modbus TCP server receives requests and can decide, in flow logic, whether to: - answer locally from a buffer / cache / register set, similar to the current server behavior - relay the request through a Modbus client - apply policy decisions such as blocking specific function codes - transform or mediate requests and responses between protocols or device models This would be useful for a variety of gateway scenarios, including: - cache/proxy strategies - protocol mediation and translation (for example Modbus-to-Modbus, Modbus-to-BACnet, Modbus-to-Sparkplug, or Modbus-to-OPC UA) - security filtering and policy enforcement (edge and data diode applications) - selective local handling vs upstream forwarding - edge-side normalization of device data and command semantics I am primarily targeting PCs, but I am also testing on a Wago CC100, which is interesting for this use case because it has two Ethernet ports plus RS-485.