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

DOOR.SYS line 1 has three Synchronet-originated extensions beyond the plain `COMn:` form:

```
COM0:STDIO use stdio
COM0:SOCKET### use socket descriptor ###
COM0:HANDLE### use Win32 comm handle ###
```

They were introduced in 509eb55226 (shape-9-quit, 2006-02-14) in our OpenDoors fork ("Add support for three new line1 types in door.sys"), and a second parser was added to `src/xpdoor/dropfiles.c` in 3ad89d745c (notes-15-like, 2009-02-07). Both are readers.

Synchronet itself never writes them. `xtrn_sec.cpp` writes `COM0:` for a local session and `COM<n>:` otherwise, including when the door is configured for stdio. So an OpenDoors door running under Synchronet cannot learn its socket from DOOR.SYS; it has to be given `-SOCKET` on the command line, or use DOOR32.SYS.

The value is already at hand -- it is what we write to DOOR32.SYS line 3 (`client_socket_dup`).

Two things worth deciding together:

1. Should `xtrn_sec.cpp` emit `COM0:SOCKET<descriptor>` for a socket door, and `COM0:STDIO` when `XTRN_STDIO` is set? Both in-tree parsers already accept it.
2. Is there any BBS other than Synchronet that writes this form? If not, the format has readers and no producers, and documenting it as Synchronet-specific (or retiring it) may be better than spreading it further.

Worth noting for the docs either way: these are ours, not GAP's. GAP BBS was a DOS/serial product and never had anything to do with sockets. Our reference material and third-party door documentation both tend to describe the socket capability as belonging to the "GAP form", which only means the `COMn:`-shaped DOOR.SYS variant that the extension attaches to.

Found while comparing our DOOR.SYS generation against the OpenDoors and xpdoor parsers.

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