Improve Running Task Log behavior based on Client subscription state

Current Situation

• While a job is running, the Log display is based on reading a history file specific to that job.
  • This file is polled periodically, and whenever new content is added, it is sent to the client that requested the Log via the log web service.
  • If the client is no longer interested in the Log (e.g., the Log window is closed), the Running Task Log API continues to poll the log file and push updates - even though there is no active subscriber.
    • This continues only for "long-running" jobs, up to a maximum of 10 minutes.
    • For "short-running" jobs, the Running Task Log stops as soon as the job completes.
• Additionally, the Running Task Log API keeps sending log content until a maximum log size limit is reached (configured via Settings->joc->log_maximum_display_size, typically 10MB).
  • This behavior is acceptable when the log is actively being viewed in a browser.
  • However, in special cases - such as when the Running Task Log API is used for live monitoring - this behavior prevents further log output from being sent, effectively blocking real-time monitoring.

Desired Behavior

• The reading and polling of the running log should actively respond to the client’s subscription state.
  • If a client unsubscribes (e.g., by closing the log window), the polling process should terminate immediately, rather than continuing unnecessarily - even in the case of long-running jobs.
• In live monitoring use cases - the log_maximum_display_size limit should not prevent logs from being delivered as long as there is an active client consuming the output.