fix(qsl): every confirmation service has a default, and the wiki explains them

HAMLOG.online was added after most profiles were configured, so it had no
entry in the shipped defaults and no stored value either: it came back
blank, and blank is not a status anybody chose. Every service now starts
the same way — the sent side at R, the received side at N — and a blank
left by a service that did not exist when the operator last saved is
filled in from that. A status they chose themselves is untouched.

Two tests hold the line: no sent side may default to Y, and no field may
be left without a default. Y means "already sent", so it makes the
uploader skip the contact for ever — an operator with eQSL Sent at Y had
a logbook that never reached eQSL, and the only trace was one line in the
application log.

Wiki, both from operator reports:

QSL Management opens with Confirmations — what the page actually is (the
status stamped on every new QSO, not an action), what each status does,
and the warning about Y in the plainest words available, because it fails
silently and by design.

Digital Modes and GridTracker is new. Unicast and multicast explained
from the operating problem rather than the networking: one letterbox that
two programs watch, against a broadcast everyone can tune to. It carries
the real evidence — two starts of one station an hour apart, decodes in
the second and none in the first, the only difference being whether
GridTracker or OpsLog reached port 2237 first — then the settings for
WSJT-X, JTDX, MSHV, GridTracker and OpsLog, the 127.0.0.1-in-the-group-box
mistake, what to do if unicast is unavoidable, and how to check it from
the log.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

wiki/Connections.md

@@ -31,6 +31,15 @@ WSJT-X and MSHV normally broadcast to a **multicast group** (usually
 give the group. A program sending to one address only needs unicast — leave it
 unticked.
 
+If you also run **GridTracker**, or anything else that listens to your decoder,
+read [[Digital Modes and GridTracker]] first: two programs on one unicast port
+work or not depending on which started first, which is the usual cause of
+"the decodes arrived yesterday and not today".
+
+A multicast group is an address between `224.0.0.0` and `239.255.255.255`.
+`127.0.0.1` is not one — a row ticked *Multicast* with a loopback or LAN
+address in the group box listens on unicast instead, and says so in the log.
+
 > **Do not put an inbound row and an outbound row on the same port.** OpsLog
 > then receives its own messages, and something it publishes can come back as a
 > command. It says so in the log when it spots the arrangement: