docs(ios): record SpringBoard sessions as verified on a physical iPhone

src/commands/schema/cli-help-topics.test.ts

@@ -514,7 +514,7 @@ test('usageForCommand resolves ios-system-ui help topic', async () => {
   assert.match(help, /discover them from the current snapshot/);
   assert.match(
     help,
-    /verified on iOS simulator; physical-iPhone SpringBoard support is not yet verified/,
+    /This workflow is verified on iOS simulator\. On a physical iPhone, opening SpringBoard, snapshot -i, and selector presses on visible home-screen icons are verified; the widget add\/edit\/remove steps are not yet verified on a physical iPhone/,
   );
   assert.match(help, /Do not hard-code Edit\/Done\/Add Widget or other SpringBoard label text/);
   assert.match(help, /Reopen the app bundle under test/);

src/commands/schema/cli-help.ts

@@ -526,7 +526,7 @@ For iOS SpringBoard, widget, or other system-UI surfaces, read agent-device help
 
 Use this when a task needs iOS SpringBoard (home screen), widget add/edit/remove, or other system-UI surfaces instead of the app under test.
 
-This works today by opening SpringBoard as the session app; there is no separate widget/system command. System labels vary by iOS version and locale, so discover them from the current snapshot instead of relying on the literal strings shown below. This workflow is verified on iOS simulator; physical-iPhone SpringBoard support is not yet verified.
+This works today by opening SpringBoard as the session app; there is no separate widget/system command. System labels vary by iOS version and locale, so discover them from the current snapshot instead of relying on the literal strings shown below. This workflow is verified on iOS simulator. On a physical iPhone, opening SpringBoard, snapshot -i, and selector presses on visible home-screen icons are verified; the widget add/edit/remove steps are not yet verified on a physical iPhone.
 
 Core loop:
   1. Reach the app state you want to prepare (for example, arrange the widget/Live Activity data the app should show) with normal app automation, then agent-device open com.apple.springboard --platform ios. From an existing app session, agent-device home first also lands on the home screen, but open com.apple.springboard is what actually binds the session to SpringBoard for selector-driven commands.

website/docs/docs/commands.md

@@ -1138,7 +1138,7 @@ For CLI-discoverable setup guidance, run `agent-device help physical-device`.
 
 For CLI-discoverable workflow guidance, run `agent-device help ios-system-ui`.
 
-- `agent-device open com.apple.springboard --platform ios` binds the session to SpringBoard. This is verified on iOS simulators only; physical iPhones are unverified (see [#1296](https://github.com/callstack/agent-device/issues/1296)).
+- `agent-device open com.apple.springboard --platform ios` binds the session to SpringBoard on iOS simulators and physical iPhones. On a physical iPhone, `snapshot -i` and selector presses on visible home-screen icons are verified; the widget add/edit/remove flow below is verified on simulators only (see [#1296](https://github.com/callstack/agent-device/issues/1296)).
 - The full widget add/edit/remove flow is selector-driven from a fresh `snapshot -i`, except two coordinate-based steps: the empty-space long-press that enters edit mode, and the widget-gallery search-result rows, which return unlabeled accessibility nodes.
 - SpringBoard labels vary by iOS version and locale; discover them from the current snapshot rather than hard-coding strings like `Edit` or `Add Widget`.
 - Reopen the app bundle under test to return to normal app automation after a SpringBoard step.