migrate pyqt5 to pyside6

README.md

@@ -4,14 +4,21 @@ Desktop applications that consume the Orisys SDK.
 
 | App | Status | Qt binding |
 |-----|--------|-----------|
-| `apps/studio` | Scaffold shell (theme / locale / prefs / logging) | PyQt5 |
+| `apps/studio` | The customer-facing shell (theme / locale / prefs / logging, acquisition, 3D) | **PySide6** |
 | `apps/autocal` | Internal 5-axis calibration platform control | **PySide6** |
 | `apps/internal` | Stub, superseded by `apps/autocal` | — |
 
-The two shipped apps use different Qt bindings on purpose. PyQt5's free option
-is **GPLv3-or-commercial**; PySide6 is **LGPLv3**, which is why the internal
-closed-source tool uses PySide6 and why `shared/` must import neither binding.
-Migrating `apps/studio` to PySide6 is a separate, build-validated change.
+Both shipped apps are **PySide6** — Qt's **LGPLv3** binding. PyQt5's free option is
+**GPLv3-or-commercial**, which is why the studio was migrated off it: a closed-source
+product would otherwise need a licence purchase. The rule is enforced, not just
+documented: neither app may import PyQt5/PyQt6/PySide2, and `shared/` (used by both) may
+import PySide6 and nothing else. See `apps/studio/tests/test_binding_purity.py` and
+`apps/autocal/tests/test_binding_purity.py`.
+
+One practical consequence: `pyqtgraph` binds to whichever toolkit it imports first, so a
+development environment that still has PyQt5 installed can build plots from the wrong
+binding. `orisys_studio.main` sets `PYQTGRAPH_QT_LIB=PySide6` before anything imports it,
+and the purity test asserts that importing the app pulls in no other binding.
 
 ## Layout