SERVING.md: two-view point-map demo (kitchen 00/03)

SERVING.md

@@ -194,11 +194,16 @@ EOF
   keys are dropped before the strict load check) -- it is not ported and never used by the
   server. The harnesses' torch reference uses the same loader, so PCC comparisons are
   unaffected.
-* **Host harnesses** (`code/test_vggt.py`, `code/eval_vggt.py`, `code/make_demo.py`,
-  `code/profile_tracy.sh`) no longer hardcode `/home/ttuser` paths: set `TT_METAL_HOME`
-  (and `VGGT_REF` if the upstream checkout is not on `PYTHONPATH`, `TT_DEVICE_ID`,
-  `VGGT_CO3D_ROOT`, `VGGT_DEMO_IMAGE`, `VGGT_MEDIA_DIR`). `make_demo.py` still needs
-  torchvision + matplotlib (host only, never shipped in the image's runtime set).
+* **Host harnesses** (`code/test_vggt.py`, `code/eval_vggt.py`, `code/profile_tracy.sh`)
+  no longer hardcode `/home/ttuser` paths: set `TT_METAL_HOME` (and `VGGT_REF` if the
+  upstream checkout is not on `PYTHONPATH`, `TT_DEVICE_ID`, `VGGT_CO3D_ROOT`).
+* **Demo** (`code/make_demo.py`): posts two views (`media/source_1.png` + `media/source_2.png`
+  = the upstream `kitchen` frames 00 / 03 by default) to a running server and renders
+  `media/pointmap.png` -- the two inputs and the union of both views' `world_points` (all in
+  the camera-1 frame) from two viewpoints; `--save-response` keeps the raw JSON/npz,
+  `--from-response` re-renders it offline, `--local` runs `vggt_forward` on the device
+  instead of the server. Client side needs numpy + pillow + matplotlib only (host only,
+  never shipped in the image's runtime set).
 * **Hardware-validated, legacy path (2026-09-12, one p150a, the built image `3c8dab9c42a2` via
   `tt-model serve`; re-measured 2026-09-13 as `TT_FUSED=0`: S=1 forward 1602 / 1517 / 1674 ms over 30 warm requests, S=2 2887; the fused default's numbers are in section 5)**: ready in 2m 0s (weights loaded 10.9 s, warm-up of S=1..4 1m 47 s;
   per-S pre-warm 49.6 / 14.8 / 20.2 / 20.4 s), `smoke_test.py` PASS at S=1 (forward