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

## Summary

Outbound-only STATIC services (IRC bots, MRC connectors, message-network pollers, RSS / webhook fetchers, etc.) currently have to declare a `Port=N` in `services.ini` with `N > 0`, even though they never accept incoming connections. Synchronet binds a listen socket on that port, the socket sits idle for the life of the BBS, and the port can't be reused by anything else on the host.

Requesting a new option flag (`NO_LISTEN` or similar) that tells the services subsystem to skip the bind for a STATIC service and start the script directly.

## Current Behavior

```ini
[GuruIRC]
Port=0
Options=STATIC | NO_HOST_LOOKUP
Command=chat_ircbot.js
```

logs:

```
Ignoring service with invalid port (0): GuruIRC
```

Source: `src/sbbs3/services.cpp`:

```cpp
if (serv.port == 0) {
lprintf(LOG_WARNING, "Ignoring service with invalid port (%s): %s", p, sec_list[i]);
continue;
}
```

So sysops are forced to pick some unused port, document it as "phantom / unused" in comments, and hope nothing else on the host ever wants it. Several deployments I've seen in the wild use `Port=6666`, `Port=7777`, or just whatever sticks -- it's a pure-magic-number wart.

## Proposed Behavior

Add a new option flag bit (let's call it `SERVICE_OPT_NO_LISTEN`, parsed from the string `NO_LISTEN` in `Options=`). When set on a STATIC service, the services subsystem:

1. Does not parse / require / bind `Port` (treats `Port=0` as legitimate, or ignores Port entirely)
2. Starts the static service thread directly with no listen socket

For example:

```ini
[GuruIRC]
Options=STATIC | NO_LISTEN | NO_HOST_LOOKUP
Command=chat_ircbot.js
```

Backward compatible -- existing configs that include a Port and don't set `NO_LISTEN` continue to bind as today.

## Motivation

The chat_llm IRC bot adapter at `exec/chat_ircbot.js` (vert's deployment) is one example -- it connects outbound to `irc.synchro.net:6667`, joins `#synchronet`, and never accepts an incoming connection. Picking a phantom listen port (currently `16667`) on the BBS host serves no purpose.

The same pattern shows up for:

- The MRC connector (`exec/../xtrn/mrc/mrc-connector.js`) -- it connects out to a chat hub
- Hypothetical RSS / webhook pollers that fetch from external feeds
- Future bot adapters (Discord, Matrix, Mastodon, etc.) that connect out

All of these are "scheduled outbound client" services that the services subsystem is otherwise the perfect host for (lifecycle, logging, recycle integration, sysop-familiar config) -- except for the forced listen-socket requirement.

## Alternative Considered

Running these scripts via `jsexec` directly, outside the services subsystem, sidesteps the port wart entirely. But then sysops have to manage start/stop/restart by hand (systemd unit on Linux, Task Scheduler on Windows), lose the auto-recycle integration with the BBS, and lose log-routing into the standard Synchronet log. Worth it for one-offs, not as a general pattern.

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