schcom: prove two clients and stacking order

The compositor already walked a surface table, but nothing had ever run
two clients at once, so "it composites" rested on a single rectangle.

schcom-test now starts two overlapping clients and checks the overlap
region from the host: the later surface has to win there. A compositor
that cannot order two surfaces cannot host a window manager, and that is
the property SchWM will be built on.

Two bugs in the test itself, both of which would have read as compositor
faults:

  - it waited for the first "committed" line and screenshotted then, so
    the second client had not drawn yet. It waits for both now.
  - one probe point sat at 400,300 -- dead centre of an 800x600 screen,
    which is exactly where the pointer is drawn. Moved clear of it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

projects/schcom/README.md

@@ -16,7 +16,9 @@ and Schcom exposes a protocol for it rather than implementing policy itself.
 commits; the result is composited and presented. Verified end to end by
 `make schcom-test`, which boots SchOS, runs the compositor and a client, then
 screendumps the framebuffer and asserts the pixels **from the host** — the
-compositor's own report that it composited something proves nothing.
+compositor's own report that it composited something proves nothing. It runs
+two overlapping clients and checks that the newer one wins in the overlap: a
+compositor that cannot order two surfaces cannot host a window manager.
 
 What exists:
 
@@ -26,6 +28,7 @@ What exists:
 - surface / attach / **commit** semantics: nothing is shown mid-draw
 - input from `/dev/input/eventN`, routed to the topmost surface
 - clients that die are cleaned up, including their shm segments
+- **multiple clients**, composited bottom-to-top in creation order
 
 What does not exist yet: damage tracking beyond "repaint everything", multiple
 outputs, subsurfaces, and any focus model beyond "topmost". Those are additions