Make the screen come back on the machine people actually run

Found by running it: Grid exits and the shell prints its prompt into the
grid, with the view up to seven pixels out of alignment. Three faults, and
the first is the one that made the other two visible.

MAKE RUN-VOYAGER HAD NO SCRATCH DRIVE. It gives drive 1 to Disks/personal.img,
which is a file and not volatile, so there was nowhere to keep a screen -
osTakeScreen answered no and the whole feature silently did not happen. It
was tested with --ram-disk and shipped without one, which is as good a
description of testing the wrong machine as I can write. There is now a RAM
disk in drive 2, after the personal disk so that drive 1 stays the one that
is yours.

A PROGRAM TOLD NO MUST COPE. A refusal is not a fault, it means doing what
the program did before there was anywhere to save a screen. Grid deleted
its own tidying up when it started asking, so being refused left the grid
on screen with a prompt written into it. It clears up again when refused,
and only then.

AND THE SYSTEM ALWAYS LEAVES THE SCREEN USABLE. The fine scroll registers
go back to zero at every program exit, whether or not the picture could be
saved: the console draws in whole cells, so a view three pixels into one
puts every character three pixels out for ever. That is not part of saving
a screen and should never have depended on it.

Both paths are checked now. With a scratch drive the screen comes back cell
for cell; without one, no grid is left behind. Breaking either fails one of
them and not the other.

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

Programs/CosmOS/README.md

@@ -843,7 +843,9 @@ walks back and forth without `Copy` itself knowing there is more than one disk.
 
 ### A Disk Of Your Own:
 
-`make run-voyager` puts a second disk in **drive 1**, at `Disks/personal.img`. It is made the
+`make run-voyager` puts a second disk in **drive 1**, at `Disks/personal.img`, and a scratch
+drive made of memory in **drive 2**. The scratch drive is what `osTakeScreen` writes to; drive
+1 is yours and comes after nothing, so adding the scratch drive later did not renumber it. It is made the
 first time it is needed and then left alone: never rebuilt, never cleaned, never committed.
 
 That last part is the point. Everything else in this repository is made from source and can be
@@ -884,6 +886,16 @@ and console mode it already puts back. Q is zero if that was arranged; a machine
 volatile drive says no, and **a program told no should carry on regardless**, because it was
 going to before this existed.
 
+**A program told no must cope.** There is no volatile drive on every machine, and a refusal is
+not a fault - it means doing what the program would have done before there was anywhere to
+save a screen. `Grid` clears up after itself when refused, which is the difference between a
+clean prompt and a prompt printed into somebody's grid.
+
+**The system always leaves the screen usable, refusal or not.** The fine scroll registers go
+back to zero at every program exit, because the console draws in whole cells and a view three
+pixels into one puts every character three pixels out for ever. That is true whether or not
+the picture could be saved, so it is not part of the saving.
+
 **It is not automatic, and that is the point.** Saving on every program start would be cheap
 enough, but restoring on every exit would be wrong: `dir`, `Files` and `Say` print and stop,
 and their output is the reason you ran them. A program that says nothing behaves exactly as