Preserve existing log transports when modifying log config

[Copilot]

When zwave-js-server enabled websocket log streaming or accepted websocket log config updates, it could replace the driver's existing transport list. In setups where another host application had already registered transports on the shared driver, those transports could disappear and file logging would not recover.

• Root cause

  • Websocket-driven update_log_config calls were passed through with the client-provided transports array, allowing remote clients to overwrite transports owned by the embedding application.
  • The websocket log forwarder also manipulated the transport list directly, which made transport ownership brittle once multiple applications were involved.

• Server-side transport preservation

  • Added a small merge step for websocket log config updates that preserves the driver's current transports and only applies the other requested log config fields.
  • Applied this to both server-level and driver-level websocket update_log_config paths so transport ownership stays with the host application.

• Logging forwarder behavior

  • Updated the websocket logging forwarder to work on copied transport arrays when adding/removing its own transport.
  • This keeps websocket log forwarding additive: it attaches its transport while active and removes only that transport when disabled.

• Regression coverage

  • Extended the integration path to model a driver that already has a custom transport.
  • The regression asserts that the pre-existing transport survives:
    • driver.start_listening_logs
    • driver.update_log_config
    • driver.stop_listening_logs

// before: websocket clients could replace host-owned transports
driver.updateLogConfig({
  level: "info",
  transports: [],
});

// after: websocket updates preserve the driver's current transports
driver.updateLogConfig(
  preserveLogTransports(driver, {
    level: "info",
    transports: [],
  }),
);