Detect callsigns in transcripts, and say whose they are

Under the transcript, headed DETECTED CALLSIGNS:, every callsign heard in
it with the name and location on its licence.

Finding them is not one regular expression over the text as written.  A
speech recogniser is poor at callsigns -- they are not words, they are
said one character at a time -- so it breaks them wherever the speaker
paused and writes the phonetic alphabet down verbatim.  The recording that
prompted this has "Alright, KU 0W" in it, with a space; spelled out it
would have been "kilo uniform zero whiskey".  All three forms read back to
KU0W.

Not inventing them matters more.  A run of words is accepted only when
none of its parts is an ordinary English word: "or 3. Can you open 4" and
"CC1 boy", both from real transcripts here, fit the shape once the
punctuation is gone and are not callsigns.  A single token said in one
breath is still trusted, because W1BOY is a perfectly good callsign, and a
lone "a" or "i" cannot start a join or "a B4U player" becomes AB4U.
Across the 126 transcripts in the recordings directory that turns three
candidates into the one that was actually said.

Lookups use the FCC's own licence data at callook.info -- no account, no
key, the callsign the only thing sent.  They never delay the display: the
entry reads "looking up" and fills itself in, and results are cached under
~/.cache so a net recorded night after night is looked up once.
--no-lookup contacts nothing and still describes a callsign from its own
structure, the ITU prefix giving the country and the digit the US
district, which is also all there is to say for callsigns outside the US.
--callsigns prints everyone who identified themselves and where they were
heard.

Also asked: are transcripts appended to, or overwritten, when another
transmission arrives on the same frequency?  Neither could be shown from
reading the code alone, so there are now three tests that run real scans
and look at the files.  By default each transmission has a transcript of
its own -- the timestamp is in the name, so two overs cannot land on one
file.  With --combine there is one recording per frequency and therefore
one transcript, opened for append with the time of each over; a second
scan into the same directory adds to it rather than starting it over,
which is the case the last of the three tests covers.

The browser and callsign tests refuse to reach the network at all.  One
test did, quietly, and passed -- visible only because the assertion it
failed printed a real operator's address.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016PsWPTweCT6pwxKngvVxcg

packaging/make-man.py

@@ -328,6 +328,30 @@ to have each one written into the lock\-out list as it is found, so the
 scanner stops looking at it at all; with
 .B \-\-save\-lockouts
 on, that list survives a restart.
+.SH TRANSCRIPTS
+Anything the content check identifies as voice is passed to a speech
+recogniser, and the words are written to a
+.I _transcription.txt
+beside the recording. Only voice: running a recogniser over Morse or a data
+burst costs seconds and produces nothing.
+.PP
+One transcript per transmission, and none is ever overwritten \[em] the
+timestamp is part of the name, so two overs on one frequency cannot land on
+the same file.
+.PP
+With
+.B \-\-combine
+there is one recording per frequency, so there is one transcript per
+frequency, and each over is appended to it with the time it was heard. An
+unattended receiver keeps adding to that file night after night rather than
+starting it over.
+.PP
+A capture with nothing recognisable in it produces no file at all, rather
+than a directory of placeholders.
+.PP
+.BR saunterbrowse (1)
+reads these back, and lists any callsigns it finds in them with the licence
+they belong to.
 .SH HF RECEPTION
 These receivers cannot normally tune below about 24 MHz. Below that they can
 sample the antenna directly instead, which opens up shortwave: broadcast,