STATE-CURRENT + docs: first real copy executed by the physical CE; add the physical-backend guest-wiring design

- STATE-CURRENT snapshot 2026-10-01 21:05: the host RM-client ladder now
  allocates VAS+PDB+TSG+channel and executes a real 4 KiB VA-mode CE copy
  (semaphore released, dst==src) on the physical engine; next is wiring the
  live session into the guest-facing mdev/vfio path.
- docs/03-architecture/11-physical-backend-guest-wiring.md: phased design
  (P0-P6) for bridging the physical backend into the guest-facing emulation,
  with the seam table, lifecycle changes and static-config flow.
- docs/README.md: reading order updated for the new document; execution
  status refreshed.

1 files changed, 34 insertions, 32 deletions

diff --git a/STATE-CURRENT.md b/STATE-CURRENT.md
index f68fcc0..9c417e3 100644
--- a/STATE-CURRENT.md
+++ b/STATE-CURRENT.md
@@ -1,6 +1,6 @@
 # Open-IOV Current State
 
-> **Snapshot: 2026-10-01 20:12.** This is a dated public status page, not live
+> **Snapshot: 2026-10-01 21:05.** 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:
@@ -60,14 +60,16 @@ meant to execute on the physical GPU.
   cleanly with no reboot.   Since 2026-10-01 17:24 the next rung has both code
   and live results: a host resource-manager client creates memory and
   channel-group objects on the booted server, allocates and programs the
-  page-directory base of a virtual-address-space object, and **allocates a real
-  channel** on the live server. It has since filed the **first real submission
-  to the physical engine**: a copy work item was placed in the channel's GPFIFO
-  and the doorbell was rung, but the copy engine did not execute it within the
-  timeout, so no completion was observed - getting the physical channel to run
-  submitted work is the current wall. One unsafe channel variant hung the server
-  task earlier, so the fail-safe held the device and an approved reboot restored
-  it; the variant is removed from the tree. |
+   page-directory base of a virtual-address-space object, and **allocates a real
+   channel** on the live server. In cycles 18-25 it went all the way to
+   execution: the channel was bound and scheduled, a work-submit token was
+   obtained, a copy work item was placed in its GPFIFO and the doorbell rung,
+   and after the engine's fetch and method-path faults were diagnosed and fixed
+   the physical copy engine ran it - a 4 KiB copy with the semaphore released
+   and destination equal to source. Every cycle released the device cleanly
+   with no reboot; the next rung is wiring the live physical session into the
+   guest-facing mdev/vfio path
+   ([`docs/03-architecture/11-physical-backend-guest-wiring.md`](docs/03-architecture/11-physical-backend-guest-wiring.md)). |
 | Graphics (3D), video | ❌ |
 | Faults, multi-version, Windows, migration, multi-tenancy, performance | ❌ |
 
@@ -79,26 +81,24 @@ chain succeeds.
 
 ## Right now (frontier)
 
-- **Submission-rung bring-up (2026-10-01 17:24-20:12): the first real work
-  submitted to the physical engine.** A host resource-manager client now talks
-  to the booted server and the channel-allocation wall has fallen: ten
-  system-memory page-table registrations and a channel-group object are created
-  under the server's own internal handles, a virtual-address-space object is
-  allocated under the device handle, its page-directory base is programmed (the
-  earlier rejection is fixed), and a real copy-engine channel is allocated. In
-  the latest cycle the client bound the channel, scheduled it, obtained a
-  work-submit token, placed a 30-word copy work item in the channel's GPFIFO and
-  **rang the doorbell** - the first real submission to the physical engine.
-  The copy engine did **not** execute the work within the timeout (no semaphore
-  release, the channel made no progress), so completion is not yet observed;
-  making the physical channel run submitted work is the new wall. The
-  root-client allocation path remains parked after an invalid-client result. One
-  channel variant hung the server's resource-manager task; the fail-safe held the
-  device instead of handing it back in a wedged state, and an approved reboot
-  restored the distribution driver (~18:37). The unsafe variant has been removed
-  from the tree, and a decoded resource-manager log dump makes server-side
-  failures readable. Evidence: `backups/evidence-20261001-cycle19/` through
-  `...-cycle21/`.
+- **Submission-rung milestone (2026-10-01 17:24-21:05): real work now executes
+  on the physical engine.** The host resource-manager client allocated a
+  virtual-address-space object with a committed page directory, a channel-group
+  object and a real copy-engine channel, bound and scheduled it, obtained a
+  work-submit token, and filed a copy work item in the channel's GPFIFO. The
+  engine's first fetches faulted; draining and decoding the status queue then
+  exposed the wrong virtual address in the fetch, and with that fixed the
+  physical copy engine executed the block: `REAL COPY OK sem=0xc0ffee01
+  src=0x1170d5000 dst=0x11ccbd000 bytes=4096 GPGet=1 GPPut=1 words=26
+  token=0x00000001` - a 4 KiB copy with the semaphore released and destination
+  equal to source. Every cycle ran under the supervised harness and released the
+  device cleanly (server shutdown, protected region down, distribution driver
+  rebound); no reboot was needed and the host stayed healthy. The next rung is
+  wiring this live session into the guest-facing mdev/vfio path so guest
+  submissions execute on the physical engine (phased plan:
+  [`docs/03-architecture/11-physical-backend-guest-wiring.md`](docs/03-architecture/11-physical-backend-guest-wiring.md)).
+  Evidence: `backups/evidence-20261001-cycle18/` through `...-cycle25/`, with
+  per-wall reports in `backups/evidence-20261001-reports/next/`.
 - **Physical-backend milestone (2026-10-01 16:45): the host-owned GSP-RM
   completes initialization on the real TU104 and serves the static-config
   RPC.** Three supervised cycles, no reboot, clean release each time:
@@ -423,9 +423,11 @@ Work execution (host service vs client synchronization):
              launch; the queued compute pushes decode but are not executed
  [partial] GPU VA -> guest PA translation: page-table walk fixed and succeeding;
            server-owned page-table population still in progress
- [partial] real work submitted to the physical GPU: a copy work item was placed
-           in a real channel's GPFIFO and the doorbell rung; the engine did not
-           yet execute it (no completion)
+ [done]    real work executes on the physical GPU: the host RM client's copy
+           engine block runs on the physical CE - 4 KiB copied, semaphore
+           released, destination equals source
+ [not yet] guest-submitted work relayed to the physical engine (next rung:
+           wire the physical session into the mdev/vfio path)
  [not yet] correct results (vectorAdd)
 ```