docs: merge the legacy flat documents, add the CUDA deep-dive and link checks

* Merge and remove the pre-reboot flat documents, preserving their still-useful
  material in the structured tree: debugging workflows and the EPT-livelock
  case study (05-operations/02), performance microbenchmarks and A/B
  methodology (05-operations/01), the version-upgrade runbook
  (05-operations/02 section 4, with corrected host/guest framing), kernel-code
  pitfalls (07-developers) and the OpenRM build/load order
  (03-architecture/06 section 7). The remaining legacy files were verified
  redundant and removed.
* docs/README now records where each migrated topic lives.
* Portability: the config YAML files are called out as design targets that no
  code reads yet, with what adding support actually requires today.
* Getting started: the OpenRM step is marked optional (native vGPU-management
  workflows only; the emulated path uses the distro driver).
* tools docs: rmtool/rmtop marked as planned, pointing at the implemented
  tools/rmq subset.
* wiki: new CUDA-Userspace-Driver deep-dive page (public-safe, links the
  canonical userspace/cuda analysis) and index update.
* scripts/check-docs-links.py plus a CI step so relative links cannot rot.
* STATE.md references to removed documents repointed.

1 files changed, 27 insertions, 11 deletions

diff --git a/docs/README.md b/docs/README.md
index cee435e..ed0f206 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -153,16 +153,31 @@ decompilation record, address reference, historical protocol notes). Wiki
 pages that predate the current implementation carry a status banner naming
 the canonical document in this tree; use the banner, not the old body.
 
-Historical material is kept but must not be read as current state. The
-following carry a **superseded** banner and point at their replacements:
-`refactored-architecture.md`, `refactored-implementation-to-do.md`,
-`PORTABLE_ARCHITECTURE.md`, `GSP_EMULATION_ARCHITECTURE.md`, `ONBOARDING.md`,
-`DEVELOPMENT_WORKFLOW.md`, `PERFORMANCE.md`, `DEBUGGING.md` (sections 3–4
-remain useful case studies), `VERSION_UPGRADE.md`, `BUILD_NVIDIA_OPENRM.md`
-(historical build notes; its load order is corrected in place), and
-[`../STATE.md`](../STATE.md) (2026-09-21 snapshot). The current versions of
-those topics are `03-architecture/01`/`06`, `04-implementation/01`/`02`,
-`05-operations/01`/`02`, `06-portability`, and `07-developers`.
+The pre-reboot flat documents have been merged into this tree and removed
+(2026-09-23). Where their material went:
+
+* debugging: gdbstub/NMI workflows, the EPT-livelock case study and the
+  failure taxonomy →
+  [`05-operations/02-debugging-and-maintenance-workflows.md`](05-operations/02-debugging-and-maintenance-workflows.md)
+* performance: the microbenchmark list and the A/B methodology →
+  [`05-operations/01-performance-correctness-security.md`](05-operations/01-performance-correctness-security.md)
+* version upgrades: the firmware/driver upgrade runbook (with the corrected
+  host/guest framing) →
+  [`05-operations/02-debugging-and-maintenance-workflows.md`](05-operations/02-debugging-and-maintenance-workflows.md) §4
+* kernel-code pitfalls and the must/must-not rules →
+  [`07-developers/onboarding-and-standards.md`](07-developers/onboarding-and-standards.md)
+* the OpenRM build/symbol/load order →
+  [`03-architecture/06-host-module-and-hybrid-model.md`](03-architecture/06-host-module-and-hybrid-model.md) §7
+* architecture, portability and implementation-plan material is now covered by
+  [`03-architecture/01-system-overview.md`](03-architecture/01-system-overview.md),
+  [`03-architecture/06-host-module-and-hybrid-model.md`](03-architecture/06-host-module-and-hybrid-model.md),
+  [`04-implementation/01-known-knowns-and-unknowns.md`](04-implementation/01-known-knowns-and-unknowns.md),
+  [`04-implementation/02-practical-challenges-and-adversarial-interop.md`](04-implementation/02-practical-challenges-and-adversarial-interop.md)
+  and [`06-portability/hardware-software-matrix.md`](06-portability/hardware-software-matrix.md).
+
+What remains historical is the pre-supersession wiki material, `old/ARCHITECTURE.md`,
+and [`../STATE.md`](../STATE.md) (a 2026-09-21 snapshot); their status banners
+name the canonical document.
 
 ## 5. What makes Open-IOV different?
 
@@ -190,7 +205,8 @@ the stack has to be modified or licensed.
   valuable thing you can send — especially non-Turing hardware, Windows
   guests, and non-KVM hypervisors.
 * **Extend it.** The architecture docs mark the interfaces that are expected to
-  grow (memory model, forwarding backends, config-driven portability).
+  grow (memory model, forwarding backends, profile-based portability — a design
+  target today, see [`06-portability/hardware-software-matrix.md` §6](06-portability/hardware-software-matrix.md)).
 * **Integrate it.** If you build a hypervisor, an edge platform or a security
   stack, see [`08-ecosystem/haaeep-and-collaboration.md`](08-ecosystem/haaeep-and-collaboration.md).
 * **Fund or co-develop it.** Commercial use is explicitly welcome under