doc: explain what a JEDEC ID is

The bscan_jedec command and tutorial referenced the JEDEC ID without
defining it. Describe the 0x9F RDID command and the manufacturer +
device byte layout, in the tutorial and the command help.

doc/tutorial.md

@@ -233,10 +233,24 @@ part is wiped and replaced by the proxy. This is undone by a
 power-cycle (the configuration flash reloads the original design at the
 next boot), but be aware the board stops doing whatever it was doing.
 
-`bscan_jedec` issues `0x9F` + 3 read bytes through the proxy. A sane
-answer (here `0x20` = Micron, the KCU105's config flash) confirms the
-whole proxy path end to end: the `bscan_spi_xfer()` framing, the
-MSB-first bit order, and the TDO read-latency skew.
+`bscan_jedec` issues the SPI **Read Identification** command (`0x9F`,
+also called RDID) and reads back 3 bytes — the chip's *JEDEC ID*. JEDEC
+is the standards body (JESD216 / JEP106) that defines this identifier;
+every serial flash answers `0x9F` the same way:
+
+- **byte 0** — manufacturer, a code assigned by JEDEC (`0x20` Micron,
+  `0xEF` Winbond, `0xC2` Macronix, `0x01` Cypress/Infineon, `0x9D`
+  ISSI, …);
+- **bytes 1–2** — device ID (memory type + capacity), vendor-specific.
+
+So the JEDEC ID is how you discover *which* flash is wired up without
+prior knowledge — Phase 3 will use it to look the part up in a chip
+database and pull its page/sector sizes and command set.
+
+A sane answer here (manufacturer `0x20` = Micron, the KCU105's config
+flash) also confirms the whole proxy path end to end: the
+`bscan_spi_xfer()` framing, the MSB-first bit order, and the TDO
+read-latency skew.
 
 ### The transfer primitive