docs: add the full-system picture and interaction/scheduling diagrams

- new 03-architecture/09-full-system-picture.md: end-state map, GSP boot,
  guest init, RPC lifecycle, memory model, work path (bridge and end state),
  scheduling, isolation levels, KVM/mdev/VFIO, BAR/engine/channel/GMMU,
  portability, performance model, implementation/test status
- new 03-architecture/10-interaction-and-scheduling.md: interaction inventory,
  control-plane call path, msgq element lifecycle, channel pump, concurrency,
  timing budgets, multi-tenant scheduling, teardown ordering, versioning
- README: mermaid system diagram replaces the ASCII block; reading list
  extended and renumbered
- component docs: GSP boot sequence, mdev/VFIO lifecycle, end-state
  interaction sequence; STATE-CURRENT links

1 files changed, 18 insertions, 15 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index c00231b..584b232 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-09-29 15:25.** This is a dated public status page, not live
+> **Snapshot: 2026-09-29 16:04.** This is a dated public status page, not live
 > state; it is refreshed on every progress check. Live working notes are
 > maintained outside this repository; the public known-knowns/unknowns document
 > is authoritative here:
@@ -49,21 +49,22 @@ chain succeeds.
 - The per-channel completion counters in guest memory are enumerated,
   registered and published; the client's per-channel waits clear, and the
   per-channel GPFIFO work on copy channels is consumed.
-- Both engine push-buffer streams are now reachable: the copy-engine buffer is
-  resolved deterministically (function-trace pointer chain, all pages pinned),
-  and the compute-engine mapping window is being pinned from guest page tables
-  on every boot.
+- Both engine push-buffer streams are reachable: the copy-engine buffer is
+  resolved deterministically, and the compute-engine mapping window plus
+  GPFIFO rings are pinned from guest page tables on every boot (a guest-side
+  scanner streams page-map deltas to the host).
 - **The copy-engine data path executes**: decoded method streams run in
-  sustained fashion (memsets, copies, releases climbing; thousands of push
-  entries consumed).
-- **Frontier: context creation still times out on one completion.** The final
-  wait is a tracking semaphore whose release was decoded from a readable
-  compute push but could not be applied in time because the counter page had
-  no translation at that moment. The fix in progress is to pin the
-  compute-channel mapping window from guest truth at boot so the release
-  lands before the client's deadline.
-- Active work: the per-boot compute-window pin stream and re-running the full
-  cycle.
+  sustained fashion (memsets, copies, releases; thousands of push entries
+  consumed), and compute-channel releases decode.
+- **The tracking-semaphore wall is solved**: live captures show completed
+  counters ahead of queued before the client fails. The remaining frontier is
+  **phase timing**: the guest's context-initialization phase (a burst of
+  channel allocations and emulated round trips) consumes nearly all of its
+  own ~15-20 s budget, so the last channels' completions arrive late. Work is
+  focused on faster counter auto-registration and cheaper replies in the
+  allocation burst.
+- Active work: fitting the whole initialization phase inside the client's
+  deadline, then the memory-allocation roundtrip.
 - Execution backend (chosen, not started): the module will own the physical
   GPU and run its real GSP firmware as the resource-manager server, so real
   work executes with an unmodified host driver and no host daemon; see
@@ -233,6 +234,8 @@ device.
 - [`docs/04-implementation/01-known-knowns-and-unknowns.md`](docs/04-implementation/01-known-knowns-and-unknowns.md) - known-knowns, known-unknowns, definition of done
 - [`userspace/cuda/READ-ME-FIRST.md`](userspace/cuda/READ-ME-FIRST.md) - CUDA analysis entry point
 - [`docs/03-architecture/08-physical-gpu-integration.md`](docs/03-architecture/08-physical-gpu-integration.md) - chosen execution backend (module-owned GPU + real GSP session)
+- [`docs/03-architecture/09-full-system-picture.md`](docs/03-architecture/09-full-system-picture.md) - visual end-to-end system map with status tags
+- [`docs/03-architecture/10-interaction-and-scheduling.md`](docs/03-architecture/10-interaction-and-scheduling.md) - cross-component interaction, queues, interrupts, scheduling detail
 - [`STATE.md`](STATE.md) - 2026-09-21 historical snapshot
 
 ---