Stop the prompt writing off the front of its own buffer

The prompt is the working directory's path, worked out each time by walking
the chain of parents up to the root. The names arrive deepest first, so
they are written backwards from the end of a 127 byte buffer - and nothing
bounded that walk.

Nothing bounds the depth either. A path given to one operation is capped at
95 characters and a 22 character name, but "mkdir a" and "cd a" are each
far inside that and can be repeated forever. Six directories of 22
characters is 132 characters of path, and at that point the walk wrote down
past the front of CwdText and into what the assembler had laid out below
it: the shell's own command names. ExitName sits five bytes under, so the
word "exit" went first and the shell stopped recognising the command for
leaving. Measured, not deduced: fine at five levels, gone at six.

The walk now counts the room it has left, byte by byte, and stops. What is
already written is the DEEP end of the path, which is the end worth
showing, so it is cut at the front and three dots say so - out of three
bytes held back from the count, so there is always somewhere to put them.
Twenty levels deep the prompt shows the last five and every command still
works.

cosmosDeep records that, and records it by running help, cd and exit from
down there rather than by looking at the prompt: a wrong prompt is
cosmetic, and this was writing into other variables. It fails with the
bound removed. The tree is built by SplitDisk because a path that long
cannot be given to mkdir in one piece - which is the same fact that makes
the depth unbounded.

The three path limits are written down in the README now, including which
one actually binds. The other two do not: the longest path on a full
install is 21 characters.

Programs/CosmOS/README.md

@@ -185,6 +185,29 @@ has moved about on looks exactly as it always did. Nothing stores the path: the
 directory is an entry index and two bytes, and the text on the prompt is worked out again
 each time by walking the chain of parents upward.
 
+That walk goes from where you are up to the root, so the names arrive deepest first and
+are written into the buffer **backwards, from its end**. When they do not all fit, what is
+already down is the deep end of the path, which is the end worth keeping - so the prompt
+is cut at the front and says so:
+
+```
+...opqrst03/abcdefghijklmnopqrst04/.../abcdefghijklmnopqrst08>
+```
+
+**Three limits, and the smallest is not the one you would guess.** A path handed to any
+one operation is capped at 95 characters up to the last separator plus a name of 22; the
+host tool carries 512, which only means it can build a tree CosmOS cannot name in one
+piece. Neither of those binds anything: the longest path on a full install is 21
+characters. What binds is the prompt's 127 bytes - and **nothing caps how deep the
+directories go**, because `mkdir a` and `cd a` are each well inside every limit and can be
+typed all day.
+
+Before the walk was bounded it wrote past the front of that buffer and into whatever the
+assembler had put below it, which was the shell's own command names. Six directories of 22
+characters was enough. The first five bytes to go were the word `exit`, so the shell
+stopped recognising the command for leaving - a fault with no plausible connection to the
+directory you happened to be standing in.
+
 `dir` lists the directory you are in rather than the whole disk.
 
 A program can move too, with `osChangeDir`, and **the shell puts the working directory