session 3 commit 3/3: doc the daemon's --features crdt requirement

Surfaced during manual validation: the pmacs-gpu window sits on
'(connecting...)' forever when attaching to a daemon built without
--features crdt. Handshake succeeds (negotiation reports semantic_render
+ crdt_replica as agreed by both sides), but the daemon's
crdt_replica default is cfg!(feature='crdt')=false in that build, so
send_buffer_snapshots() never fires and pmacs-gpu has nothing to
render.

Classified small under rule (iii). The structural answer (should the
daemon return a clearer signal when crdt_replica was negotiated but
isn't actually compiled in?) is genuine but deferred; for session 3
the failure mode is now documented inline at the build-AttachRequest
site so the next user to hit it recognizes the symptom.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

pmacs-gpu/src/attach.rs

@@ -113,6 +113,17 @@ pub fn connect(
     // AttachRequest — declare the capabilities a semantic frontend
     // needs. `multi_frontend` is included because the existing daemon
     // gates `crdt_replica` behind it (M10.x dependency).
+    //
+    // **Daemon requirement**: the daemon must be built with the
+    // `crdt` feature (`cargo run --features crdt --bin pmacs --
+    // --daemon ...`). Without it the daemon's
+    // `InstanceCapabilities::default` returns `crdt_replica: false`,
+    // negotiation succeeds but no `BufferSnapshot` ever arrives, and
+    // the `pmacs-gpu` window sits on `(connecting...)` forever. This
+    // surfaced as a session-3 finding when manually validating the
+    // attach loop; classified as small under rule (iii) — recorded
+    // here so the next person attaching against a non-crdt daemon
+    // recognizes the symptom immediately.
     let req = AttachRequest {
         protocol_version: hello.protocol_version,
         frontend_capabilities: FrontendCapabilities {