Make the process of adding an orca extension easier.

tests/README.md

@@ -102,12 +102,29 @@ The controller test drives the helper through a native Windows NVDA RPC client.
 It verifies speech, cancellation, braille, SSML status forwarding, reader loss,
 invalid reader values, and startup refusal when only the unselected service
 exists. Both service names are owned while the selected reader handles requests.
+It also rejects invalid endpoint overrides, missing objects/interfaces,
+missing required methods and incorrect input/output signatures.
 The menu/editor and review tests also accept `--reader cthulhu`; omit the option
 to check existing default behavior. Review checks reject callers even when they
 own the unselected service, then replace the selected service owner and verify
 registration and capture access move to the new owner. Its provider object path
 and interface remain the same for both readers.
 
+To check an Orca extension endpoint, add `--extension-endpoint`:
+
+```sh
+xvfb-run -a python3 tests/controller_integration.py --build-dir build --reader orca --extension-endpoint
+xvfb-run -a python3 tests/menu_integration.py --build-dir build --reader orca --extension-endpoint
+xvfb-run -a python3 tests/menu_integration.py --build-dir build --reader orca --extension-endpoint --fixture edit
+xvfb-run -a python3 tests/review_integration.py --build-dir build --reader orca --extension-endpoint
+```
+
+These publish `/org/gnome/Orca1/Service/WineAccess` with interface
+`org.gnome.Orca1.WineAccess`, while retaining the `org.gnome.Orca1.Service`
+bus name. Controller checks put overrides before reader selection; control
+and review checks put them after it. Review checks still reject unrelated
+callers and transfer capture access only when the selected bus owner changes.
+
 These tests supply recording services implementing the Wine protocol; they do
 not run Orca or prove audible speech or physical braille. Stock Orca still needs
 the reader-side methods and helper lifecycle described in the