feat(nesdoctor): read the display, and offer early access

Two things, both of which every response collected without them is a response
we cannot go back for -- since a submission carries nothing that identifies
anyone, there is no second chance to ask.

## The display and decode probe

This is the readable half of the client capability probe our build order
already specifies -- GPU, decoder, display -- and its stated purpose is
attribution: told only that a stream "looks bad", the cheapest available
explanation is that our reconstruction ratio was too aggressive, so without
this we would lower the ratio and pay density for somebody else's window
manager.

  presentation path   x11 · bspwm
  eDP-1               1920x1200 @ 60 Hz, 8-bit
  Vulkan decode       h264, h265
  VA-API decode       h264, h265, vp9

Session type, compositor, and whether we are under XWayland -- which is exactly
the objection raised against our own A/B rounds, now recorded automatically
rather than argued about. A bare window manager sets none of the XDG variables,
so bspwm and thirteen others are matched from the process list; a report that
cannot name bspwm cannot answer the challenge that named it.

From EDID, parsed here rather than shelled out to: native mode, refresh,
colour bit depth, which HDR transfer functions the panel accepts, BT.2020
colorimetry, and 4:2:0 chroma. The CTA-861 extension blocks are where all the
colour capability lives -- base EDID says nothing about any of it.

That decides real choices. Whether 10-bit is worth sending, whether BT.2020 is
worth encoding, which codec to reach for. Every one of those has so far been
decided against the one panel in this room -- which this now reports as 8-bit,
meaning the 10-bit work cannot be validated on it at all.

EDID is untrusted binary from a device node. Every read is bounds-checked and
every field optional: monitors ship broken EDIDs and docks synthesise worse
ones, so a bad panel costs one field rather than the run. Three tests, one of
which truncates the block mid-extension and asserts that no colour capability
is invented. The colorimetry byte offset was wrong the first time and the test
caught it, which is the argument for the test.

Present mode, tearing and fractional scaling need a real window and swapchain,
so they are absent and said to be absent rather than guessed.

## Early access

An optional email, asked last, after the verdict has printed -- so nobody types
an address before seeing what this said about their machine. Blank skips it.

The offer branches on the verdict, because telling someone with no KVM and a
grade-F uplink that we liked what their machine can do is a lie, and this
program's only real asset is that it does not flatter anyone. A host-capable
machine gets the host offer; everyone else gets early access as a player, which
is a true offer too.

It is the one identifying thing collected here, so: it appears in the
pre-submit disclosure with everything else, and the promise elsewhere had to be
reworded -- "no username, no identifiers" stopped being true the moment this
field existed, and leaving the old line standing would have been the dishonest
option. Validation is deliberately loose; arguing with somebody about their own
address over a regex loses the response outright.

Version to 0.2.0.

apps/nesdoctor/README.md

@@ -101,6 +101,33 @@ always a router setting rather than a line you need to upgrade.
 | `CLIENT` | Not a host. A complete answer, and what most machines are |
 | `UNKNOWN` | A blocking check could not be run. An unknown is not a no |
 
+## Your display, and why we ask
+
+```
+  presentation path   x11 · bspwm
+  eDP-1               1920x1200 @ 60 Hz, 8-bit
+  Vulkan decode       h264, h265
+  VA-API decode       h264, h265, vp9
+```
+
+Read from your monitor's EDID and your session, not guessed. Resolution,
+refresh, **colour depth**, which HDR transfer functions the panel accepts,
+whether it takes BT.2020, whether it takes 4:2:0 chroma — plus what your
+hardware can decode.
+
+This decides real choices on our side: whether 10-bit is worth sending, whether
+BT.2020 is worth encoding, which codec to reach for. Every one of those had
+been decided against the single panel in one room.
+
+Its other use is **attribution**. Told only that a stream "looks bad", the
+cheapest explanation is always that we compressed it too hard — so without
+knowing that a compositor is rescaling the picture, we would turn down our own
+quality to pay for somebody else's window manager.
+
+**Present mode, tearing and fractional scaling are not here.** They need a real
+window and a swapchain, so they belong in the client, and are reported as
+unknown rather than guessed.
+
 ## Sending it back
 
 At the end it prints a link, lists in plain English what the link contains, and
@@ -122,6 +149,11 @@ for it.
 If you would rather not click a link we wrote, the short line is printed too and
 put on your clipboard.
 
+At the very end it offers to take an **email address** — optional, blank skips
+it — so we can come to you when there is something to try. That is the only
+identifying thing this program collects, it is asked last, and it appears in the
+disclosure list like everything else so you see it before it is sent.
+
 ## What it deliberately does not tell you
 
 - **A pass is not a promise.** Every check is a *necessary* condition. Nothing