Make the cursor blink while the machine is waiting, and show how the palette works

THE CURSOR DID NOT BLINK, and the reason is worth stating: it blinks on the machine's clock,
and the machine's clock had stopped. A console waiting on a key stops the CPU, so no cycles
passed, so the phase never moved - and the one moment somebody is looking at a cursor is the
moment they are being asked to type.

Waiting is now charged as IDLE CYCLES, which is what they were built for: a machine stopped
on a device is not using memory, the same distinction WAIT makes, arrived at from the other
direction. And the devices are told as it happens rather than when the instruction finally
finishes, because a display controller does not stop blinking because the processor is
waiting on a keyboard, any more than a disk stops turning.

A keyboard file can now say NOTHING happened. A zero is a byte no keyboard sends, so it is
free to mean "a moment went by with nobody typing" - which is the commonest thing behind a
window and the only thing a file otherwise could not express. That unlocked the whole waiting
path: three checks that the cursor is lit, then dark half a second later, then lit again,
which is what blinking is.

And Programs/Examples/colours.asm, because the palette had nowhere a newcomer could read it.
It prints the sixteen pairs, prints each one again turned inside out, and then CHANGES ONE by
writing three bytes into the palette - so the difference between using the colours a machine
wakes up with and choosing your own is visible in one program. Its header explains what a
cell is, what the attribute nibble does, why palette entries are four bytes rather than
three, and why video memory has to be reached through the controller.

The manual now says where the palette lives and points at it.

SplitLint found a redundant RSTA in the example, which was worth acting on rather than
suppressing: the zero was already in A from the mode write two lines up, and saying so in a
comment teaches that SETD does not touch A, which is a thing worth knowing.

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

Source/Emulator/io.h

@@ -250,6 +250,18 @@ void consoleSetInputHook(int (*hook)(int mayWait));
 // display that refreshes, a port that waits on the host - wants exactly this shape.
 void deviceTick(unsigned long now);
 
+// ---- Time that passed while the machine was stopped ----
+//
+// A console waiting on a key it has not been given has stopped the machine, and time is
+// still going by: the cursor still blinks, a disk still turns. That is exactly what idle
+// cycles are for, and without them the machine's clock froze the moment somebody was asked
+// a question - so the cursor stopped blinking precisely when there was a person looking at
+// it and waiting to type.
+//
+// Returned and cleared, the way the controller's cycles are, and picked up in the same
+// place: after a port access, by the CPU that was stopped.
+unsigned long takeIdleCycles(void);
+
 // How many cycles a block read or write takes. Zero means the answer is there before the
 // next instruction is, which is what this machine has always done and what every recorded
 // test assumes.