docs: reposition as the 86 Panel development environment

The repo's documentation framed it as a support repo for one product
(WardenOS). Since going public the real audience is anyone with a Luckfox
Pico 86 Panel: a maintained 6.18 kernel, an off-device development loop,
and a device simulator that exist nowhere else for this board. Reframe the
README and top-level docs board-first, with WardenOS documented as the
downstream consumer it is (ADR-0008).

Also an editorial pass over the whole doc set:
- every H1/H2 is now a short title, not a sentence (ADRs, qemu/, patches/,
  drivers/, architecture, NPU feasibility, config-lint, payload); workflow
  flowchart titles fixed at the source in tools/flowgen.py and regenerated
  with fresh bench numbers
- README Quick Start commands verified against the scripts; requirements
  corrected (curl, bare python, gcc >= 14) and the MC/DC gate added as a
  step (run green locally on gcc 14.2)
- dropped the 'needs python (not python3)' vendor dig: build-kernel.sh
  inherited the same requirement (filed #10 to remove it)
- glossed MC/DC and HPMCU on first use; marked the tests/uboot-ab
  reference as flare-edge; deduplicated the three-simulator list into the
  root README table

tools/config-lint/README.md

@@ -1,9 +1,9 @@
-# config-lint — static target-config gates
+# config-lint
 
-Catches flash-time config faults the behavioural sim cannot: mistakes in the
+Static target-config gates: catches flash-time config faults the behavioural sim cannot: mistakes in the
 *memory map*, not the logic. The first check is the one that would have caught the
 **c8a3 brick** — a boot-loaded coprocessor firmware dropped at `0x40000`, which is
-a `reserved-memory` carve-out on Thunder-Boot boards but plain kernel RAM on ours,
+a `reserved-memory` carve-out on Thunder-Boot boards but plain kernel RAM on the 86 Panel,
 so the MCU and the kernel fought over the same DRAM and the board hung before eth0.
 
 ## The check
@@ -37,6 +37,6 @@ found; `2` = usage/IO error.
 
 The suite encodes the brick as a regression: the real Thunder-Boot `.ini`
 (Hpmcu @ `0x40000`) *fails* against a DT with no `rtos@40000` node and *passes*
-once the reservation is added — and our board's non-TB loader (no boot-loaded MCU)
+once the reservation is added — and the 86 Panel's non-TB loader (no boot-loaded MCU)
 always passes. See `../../docs/architecture.md` §5 and, for the hardware hazard,
 the `boot-loaded-mcu-0x40000-hazard` note.