Settle is a program, and a machine with no fallback still starts

The boot state opened a loop that could not be closed from inside: the
machine said "settle it to try again" and gave you no way to do so. Settle
closes it, in 349 bytes.

A PROGRAM RATHER THAN A SHELL WORD. The shell is for the things that cannot
be done without it, and this is not one - it reaches the system through SWI
like anything else, which means it can be replaced, left off a disk, or
called by whatever comes to call programs in turn. That last one is the
point: a shell word is not callable by anything.

Two services for it. osBootState answers in Q, and a machine with no disk
answers settled, because there is nothing there to be unsettled about.
osBootSettle puts it back. SETTLING IS THE ONLY WRITE A PROGRAM GETS -
marking a start as trying or fallen back is the loader's business, and a
service that let a program claim either would let it lie about something
the loader has no way to check.

And a hole the tests walked into, which was mine rather than theirs. With
no fallback configured, a failed start left the machine unable to start at
all: the mark said do not use the system, and there was nothing else to
use. That turns "the last start failed" into "no start is permitted", which
is worse than the problem the mark was added to solve. With nothing to fall
back to it now tries the configuration again and says so - a failure that
was passing recovers, and one that is not leaves the machine exactly where
it would have been without any of this, which is the most that can be
promised when there is only one thing to start.

docs.sh caught both new services having no row in the services table before
anything else did.

Programs/CosmOS/Source/cosmos.asm

@@ -2276,6 +2276,55 @@ handlePrintNumber:
 ;
 ; Which is exactly why this cannot RETI. Its return address is on the Stack it just walked
 ; away from, so it branches to the prompt instead.
+; ---- How the last start went, and settling it ----
+;
+; The answer goes in Q by writing into this handler's own frame, which is how every service
+; here hands anything back: a handler arrives with the caller's registers pushed, not
+; cleared, and RETI puts them back - so the way to return a value is to change the copy the
+; return is going to restore.
+handleBootState:
+  SETD.2 DiskReady
+  LDA.2
+  BRA bootStateNone
+
+  CALL sbfsBootState
+  BNQ bootStateNone
+  SETD.2 SbfsStateWas
+  LDA.2
+  MVSD.2
+  DPUP.2 0d02
+  STA.2
+  RETI
+
+bootStateNone:
+  ; No disk, or one that would not answer. Nothing there to be unsettled about.
+  MVSD.2
+  DPUP.2 0d02
+  RSTA
+  STA.2
+  RETI
+
+handleBootSettle:
+  SETD.2 DiskReady
+  LDA.2
+  BRA bootSettleNo
+
+  RSTA
+  CALL sbfsSetBootState
+  BNQ bootSettleNo
+  MVSD.2
+  DPUP.2 0d02
+  RSTA
+  STA.2
+  RETI
+
+bootSettleNo:
+  MVSD.2
+  DPUP.2 0d02
+  INIA 0d1
+  STA.2
+  RETI
+
 handleExit:
   SETD.1 SystemStack
   LDD.0.1
@@ -3897,4 +3946,6 @@ CommandLine:
   osFileFetch    handleFileFetch
   osPrintNumber  handlePrintNumber
   osBreak        handleBreak
+  osBootState    handleBootState
+  osBootSettle   handleBootSettle
   Device 0x20    diskDone