Move the console into its own binary; the step was fighting the progress display

`zig build interact` shredded the editor's screen with fragments of
`[11/13] steps  +- console`. The cause is structural, not cosmetic: an interactive
step lives for as long as the human does, and `std.Progress` redraws the build
runner's step tree on stderr every 80 ms for all of it.

std already solves this, and the solution is a lock rather than a flag.
`Step.Run` with `stdio == .inherit` holds `io.lockStderr()` for the entire
lifetime of the child (std/Build/Step/Run.zig:1588-1592) - the same lock
`Progress` must take to draw. A hand-rolled step gets none of that unless it
takes the lock itself, and `ConsoleStep` did not. So the console is now a real
host program, `tools/console_main.zig`, and `console`/`interact` are `Run` steps
on it. `--color off` is not needed and is no longer suggested anywhere.

Measured under a real pty (a pipe hides the bug, because progress only draws to
a terminal - which is why every earlier end-to-end test here looked clean):
zero bytes of progress output across an 11-second session, 3 frames, the editor's
`^` modified-marker landing at row 2 after two keystrokes.

The second reason for a program is that "just connect" should not imply a build.
Once the firmware is in flash the board runs it across resets, so the common case
during use is to open the port and nothing else:

    zig-out/bin/p4-console                # the board is already programmed
    zig-out/bin/p4-console --no-reset     # ...and leave a live session running

`--no-reset` is the interesting one and it is proven on the die: attaching to the
running editor produced 309 bytes with no ESP-ROM banner and zero `boot:` lines,
then a `^` frame in response to typing. The session survived a detach and
reattach with no repaint, which is exactly what a 11.9 KB/s link wants.

`zig build console` is 4 steps and builds no image, no app and no object. It
installs `p4-console` itself rather than going through `installArtifact`, so
`zig build` alone still lands exactly one file in `zig-out` - verified from an
empty tree.

Also here:

* `tools/console.zig`'s `ModeWatch` tests were reachable by nothing. `zig build
  test` runs them now; the matcher has to resynchronise when the byte that broke
  a match is the next match's ESC, which is worth a regression test.
* The port-permission advice existed twice, in `failPort` and in the new program.
  It now lives once, in `tools/serial.zig` beside the code that opens ports, and
  says nothing about the path so each caller can name its own on the first line.

1 files changed, 21 insertions, 0 deletions

diff --git a/tools/serial.zig b/tools/serial.zig
index da225fd..3398a11 100644
--- a/tools/serial.zig
+++ b/tools/serial.zig
@@ -26,6 +26,27 @@ pub const Baud = enum(u32) {
     }
 };
 
+/// The remedy for the one error every first run hits, in the module that owns port opening so the
+/// build steps and `p4-console` cannot drift apart. Deliberately says nothing about the port's
+/// path: the caller names that on its own first line, which is the only part that differs.
+///
+/// The last case is the one worth spelling out, because it is the one that looks like the fix did
+/// not work: a shell started before `usermod` never sees the new group, since credentials are
+/// captured at login and not re-read.
+pub const access_denied_help =
+    \\  It is owned by a group your session is not in (uucp on Arch, dialout on Debian).
+    \\
+    \\  If you are NOT in that group yet, join it and log in again:
+    \\      sudo usermod -aG uucp $USER
+    \\
+    \\  If `id -nG` already lists it, this shell simply predates the change - group membership is
+    \\  captured at login. Either log out and back in, or take it in this shell:
+    \\      newgrp uucp
+    \\
+    \\  Or run one command with the group, without touching this shell at all:
+    \\      sg uucp -c '...'
+;
+
 /// `struct termios2` as the Linux kernel defines it: 19 control characters, then the two integer
 /// baud fields. std's `linux.termios2` uses NCCS = 32, which makes it 60 bytes instead of 44 and
 /// therefore encodes TCGETS2/TCSETS2 with the wrong size field - the ioctl then fails with ENOTTY.