open https://gitlab.synchro.net/main/sbbs/-/issues/1150

## Summary

`sbbsctrl` (the Synchronet Control Panel GUI) displays the Services subsystem's real-time log in its Services tab, but does not persist that output to a `.log` file on disk the way the Terminal / Mail / FTP / Web tabs do.

When a Services-launched JavaScript script (custom IRC bot, MRC connector, JSON service, etc.) calls `log()` or `lprintf()`, the resulting line scrolls past in the GUI and then is lost. Sysops debugging a Services script after the fact have no way to see what it emitted, and have to either:

- Watch the Services tab live during the entire test (impractical for things like overnight cron-like tasks or rare event handlers)
- Reproduce the issue while tailing the GUI
- Implement their own log-to-disk inside each script (the bot writes its own `data/logs/chat_ircbot.log` etc.)

The other server tabs (Terminal, Mail, FTP, Web) already support per-server disk logging via the "Log to Disk" option (the same machinery touched in `edf752429` / `1082de20d`). Services should have parity.

## Proposed Behavior

A "Log to Disk" option on the Services tab analogous to the existing one on Term/Mail/FTP/Web tabs. When enabled:

- Each log line from a Services-launched script (or from the services subsystem itself) gets written to `services.log` (or `data/logs/services-YYYY-MM-DD.log`, matching whatever the existing per-server convention is on this host)
- The disk-log stream is `fflush()`-ed per write so SIGSEGV / abend mid-line still leaves a tail you can read (matching the `edf752429` fix)
- Shutdown-summary lines aren't dropped (matching `9a207243c`)
- Sysop preference persists across `sbbsctrl` restarts via the same registry key / `.ini` pattern the other tabs use

## Motivation

This came up while debugging an IRC bot service (`exec/chat_ircbot.js`) that wasn't responding to private messages. The bot's `log(LOG_INFO, ...)` diagnostic lines were emitting -- visible in the Services tab in real time -- but couldn't be retrieved after the fact for analysis, so the bot author had to add a self-managed log-file writer just to see what target field the incoming DM PRIVMSG was carrying. That kind of workaround belongs in the framework, not in every service script.

Other Synchronet projects in the wild (MRC connector, Synchronet-MRC, third-party JSON services, custom JavaScript services-launched scripts) would all benefit from the same disk-log persistence the existing servers enjoy.

## Out of Scope

- Per-service log files (e.g., `chat_ircbot.log` separate from `mrc-connector.log`). A single combined `services.log` is fine for v1 -- sysops who want per-script separation can grep, or each script can prefix its lines. The framework's job is just to persist what `log()` already emits.

— *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)