doc: how to build a not-pre-built proxy (KU15P) in the tutorial

quartiq ships no UltraScale+ proxy, so the KU15P .bit must be built from
xilinx_bscan_spi.py (Migen + Vivado) after adding the part to the
generator's device table. Put the operational steps in the tutorial's
Phase 2.5 (where users look for a bitstream); CLAUDE.md just points to
it.

doc/tutorial.md

@@ -281,6 +281,29 @@ curl -L -o bscan_proxies/bscan_spi_xcku040.bit \
 The registry entry for the part points at this file via its
 `proxy_bitstream` field (e.g. the XCKU040 entry → `bscan_spi_xcku040.bit`).
 
+#### When your part isn't pre-built (e.g. the KU15P)
+
+quartiq ships `.bit` only for the parts its generator knows — it has
+**no UltraScale+** proxy (its single UltraScale entry is the KU040), so
+the KU15P has to be built from source. You need (o)Migen + Vivado
+(2022.2; ISE 14.7 for older parts). From a clone of the quartiq repo,
+per its README:
+
+```sh
+python3 -m venv --system-site-packages .venv
+./.venv/bin/pip install -r requirements.txt
+PATH=$PATH:/opt/Xilinx/Vivado/2022.2/bin \
+  ./.venv/bin/python3 xilinx_bscan_spi.py ...
+```
+
+The XCKU15P first has to be **added to the generator's device table**
+(a Migen platform entry) — it's not just a command-line part flag.
+
+Once built, drop `bscan_spi_xcku15p.bit` into `bscan_proxies/` (it's
+MIT, like the KU040 — keep `bscan_proxies/LICENSE.quartiq`) and set the
+`proxy_bitstream` field on the KU15P entry in `modules/fpga/fpga.c`
+(currently `NULL`).
+
 ### Load the bridge and talk SPI
 
 ```