A word the monitor does not know goes to the disk, not into the weeds

There was nothing at the end of the monitor's command list. An unrecognised word
fell off it and straight into sayPrompt - which is a ROUTINE, so its RET had
nothing of its own to return to and went wherever the Stack happened to be
pointing.

The user found it by typing a program's name at the monitor prompt, which is an
entirely reasonable thing to do: the monitor is a mode of the shell, so
everything the shell does is meant to work in it. What they got was a fault, and
before that a second prompt printed on top of the first - which is sayPrompt
doing exactly what it is for on its way past, and the tell that it had been
entered rather than called.

WHERE THAT RET WENT DECIDED HOW BAD IT WAS. Usually 0x0003, in the middle of
newLine, and the machine stopped on a byte that is not an instruction. Once it
was inside sbfsFormat, and the machine formatted the disk it had booted from -
the user's would not start again, and neither would mine, which is how I came to
have a reproduction before I had a diagnosis.

Pre-existing, and not recent: it is there at 2a29ceb and every revision I
checked back through.

The fix is one branch. cosmosMonitorRun covers all three cases the monitor now
has to handle - a program started by name, a program that faults, and a word
that is nothing at all - because the first of those is what the user did and the
last is what used to be fatal.

Worth naming as a shape: a run of tests falling through into a subroutine. The
symptom is not at the site, the failure depends on the Stack, and the damage is
whatever the return address happens to land on. SplitLint has no rule for it and
could have one.

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

Programs/CosmOS/Source/cosmos.asm

@@ -331,6 +331,20 @@ promptWhere:
   CALL textSame
   BRQ doAssemble
 
+  ; ---- And a word the monitor does not know either ----
+  ;
+  ; It goes where the shell's unknown words go, which is the disk, because the monitor is a
+  ; MODE of the shell rather than a different program and everything the shell can do is
+  ; still supposed to work in it.
+  ;
+  ; THERE WAS NOTHING HERE AT ALL, and the fall through was into sayPrompt - a routine, which
+  ; ended in a RET that had nothing of its own to return to. So it took whatever the Stack
+  ; held and went there. Sometimes that was 0x0003, in the middle of newLine, and the machine
+  ; stopped on a byte that is not an instruction; once it was inside sbfsFormat, and the
+  ; machine formatted the disk it had booted from. The tell was a SECOND prompt printed
+  ; before the wreckage, which is sayPrompt doing exactly what it is for on its way past.
+  BRI promptUnknown
+
 ; Where you are, and then the prompt itself. A routine rather than a run of code in the loop,
 ; because the loop is no longer the only thing that needs it - see shellReadTyped.
 sayPrompt: