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/Cargo.toml

@@ -2,7 +2,7 @@
 name = "warden-config-lint"
 version = "0.1.0"
 edition = "2021"
-description = "Static target-config checks for WardenOS: catch memory-map faults (the 0x40000 MCU-load brick class) and other flash-time config mistakes before a flash, not on the bench."
+description = "Static target-config checks for the Luckfox Pico 86 Panel: catch memory-map faults (the 0x40000 MCU-load brick class) and other flash-time config mistakes before a flash, not on the bench."
 license = "GPL-2.0-only"
 
 [[bin]]

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.

tools/flowgen.py

@@ -27,7 +27,7 @@ OUT = os.path.join(REPO, "docs", "workflows")
 WORKFLOWS = [
     {
         "name": "hpmcu-watchdog",
-        "title": "HPMCU watchdog: arm → beat → fire",
+        "title": "HPMCU Watchdog",
         "outcome": "A hung A7/flared ends in a counted reset, not a dark panel.",
         "metric": ("bench", "hpmcu_tick"),
         "mermaid": """flowchart TD
@@ -42,7 +42,7 @@ WORKFLOWS = [
     },
     {
         "name": "modbus-read-holding",
-        "title": "Modbus RTU: read-holding-registers round trip",
+        "title": "Modbus RTU Round Trip",
         "outcome": "A well-formed request yields the right registers; a bad one a defined fault.",
         "metric": ("bench", "modbus_read_holding"),
         "mermaid": """flowchart TD
@@ -58,7 +58,7 @@ WORKFLOWS = [
     },
     {
         "name": "cru-reset-ladder",
-        "title": "CRU reset ladder: cause + boot-mode survival",
+        "title": "CRU Reset Ladder",
         "outcome": "Reset cause is attributable and the boot-mode register survives a warm reset.",
         "metric": ("bench", "cru_poll"),
         "mermaid": """flowchart TD
@@ -71,7 +71,7 @@ WORKFLOWS = [
     },
     {
         "name": "rga-offload",
-        "title": "RGA 2D offload dispatch",
+        "title": "RGA Offload",
         "outcome": "Blits go to the RGA when it succeeds, and fall back to the CPU when it doesn't.",
         "metric": ("bench", "rga_improcess"),
         "mermaid": """flowchart TD
@@ -84,7 +84,7 @@ WORKFLOWS = [
     },
     {
         "name": "relay-drive",
-        "title": "Relay drive (Tier-1, 100% MC/DC)",
+        "title": "Relay Drive",
         "outcome": "A relay is exported transparently and driven without disturbing a held contact.",
         "metric": ("mcdc", "relays.c — 40/40 conditions, 100% MC/DC (CI-enforced)"),
         "mermaid": """flowchart TD
@@ -102,7 +102,7 @@ WORKFLOWS = [
     },
     {
         "name": "freshness-contract",
-        "title": "UI freshness contract (Tier-1, 100% MC/DC)",
+        "title": "UI Freshness Contract",
         "outcome": "The UI never shows a stale number: it holds briefly, then marks unknown.",
         "metric": ("mcdc", "freshness.c — 66/66 conditions, 100% MC/DC (CI-enforced)"),
         "mermaid": """flowchart TD
@@ -148,7 +148,7 @@ def metric_line(metric, bench):
 def main():
     bench = load_bench(sys.argv)
     os.makedirs(OUT, exist_ok=True)
-    index = ["# Workflow flowcharts", "",
+    index = ["# Workflow Flowcharts", "",
              "Generated by `tools/flowgen.py` from the modelled decision paths.",
              "Each is an outcome-first flowchart of a workflow the SDK tests, with its"
              " benchmark or MC/DC metric.", ""]