fix(web): submit live Enter and isolate stalled probes

docs/accessibility.md

@@ -1,5 +1,15 @@
 # Accessibility acceptance criteria
 
+Web selector buttons must include their full current value in the accessible name.
+Toggle controls expose pressed/unpressed state; ordinary action buttons must not be
+announced as toggles. Busy and disabled controls expose those states to browser
+assistive technology. Check the rendered DOM in addition to native prop tests.
+
+On the web, live typing must submit from both keyboard Enter and the visible Enter
+control, then restore input focus after success or failure. Failure retains text
+and offers Retry Enter. Draft Enter remains multiline. Verify these using actual
+browser keyboard events, not only React Native's synthetic submitEditing callback.
+
 Switchify Remote is designed for VoiceOver, TalkBack, iOS Switch Control, and Android Switch Access.
 
 ## Custom section layouts

docs/physical-smoke-test.md

@@ -1,5 +1,14 @@
 # Physical development-preview smoke test
 
+## Web checks
+
+In Chrome on Android against Windows and macOS, verify live keyboard Enter and the
+visible Enter control each send once, clear on success, and restore input focus.
+After failed delivery, verify text remains and Retry Enter does not duplicate the
+text. Draft Enter must insert a newline without sending. Reload the page and
+reconnect a saved PC. Check fallback selection after an unreachable remembered PC.
+Keep fake-browser checks separate from physical Bluetooth evidence.
+
 Record the app commit, Switchify PC release, phone model/OS, and desktop platform for each run. Never paste pairing credentials or typed personal content into the record.
 
 ## Layout edit mode checks

docs/web.md

@@ -34,10 +34,68 @@ Web Bluetooth is available in Chrome and Edge on Android, Windows, macOS and Chr
 
 The protocol, framing limits, authentication and pairing approval are unchanged. See [protocol compatibility](protocol-compatibility.md).
 
+First-time browser device identity creation uses an exclusive Web Lock, so tabs
+share one persisted identity. Waiting for a lock is bounded to five seconds. If
+locks are unavailable or persistence fails, initialization fails safely rather
+than using an unsaved identity. Existing encrypted identities remain readable.
+This keeps the existing keys, ciphertext format and native storage path unchanged.
+
+Connection cancellation includes initial cleanup: a stopped or replaced attempt
+must not reopen the picker or begin another connection after cleanup completes.
+
+## Typing and probe recovery
+
+Keyboard Enter in live typing sends one Enter, clears only after acknowledgement,
+and returns focus to the input. The visible Enter and Retry Enter controls use the
+same delivery path. Draft Enter continues to insert a newline without sending.
+RN Web 0.21 requires `blurOnSubmit` for this multiline live input; native platforms
+continue to use `submitBehavior` without a blur override.
+
+Remembered-device probes have disposable connections and do not occupy the active
+session's GATT queue. A stalled probe must time out and disconnect before fallback
+selection, and a late probe completion must not affect the chosen PC.
+
 ## Hardware validation still needed
 
+Connection discovery now reads status before looking up command and notification
+characteristics, one operation at a time. Only PCs advertising `read-v1` are asked
+for the read-response characteristic. Discovery shares one ten-second budget and
+checks cancellation between operations. Diagnostics identify each lookup using
+fixed labels, never browser error text or Bluetooth identifiers.
+
+Issue #182 follows a real Chrome failure after status discovery and before pairing.
+The current-code hardware retry narrowed the failure to primary-service discovery
+after reconnecting. Sequential characteristic discovery alone did not fix it.
+The web transport now explicitly retains the selected completed discovery probe
+across scan stop and connection preparation. It reuses that live service and
+rereads status before pairing; a changed desktop identity still fails. Normal
+scan stop, explicit disconnect, cancellation and failed setup close the probe.
+Native transports keep their existing preparation path. A successful real pairing
+with this handoff remains required before release.
+
 Automated tests use fake Web Bluetooth devices. Before release, check on real hardware:
 
 - pairing and control from Chrome on Android against Switchify PC on Windows and on macOS
 - that 182-byte writes are accepted on each PC platform, and the reconnect behaviour after a PC restarts
 - saved-PC reconnection after a browser restart, both with and without `getDevices()` support
+
+## Browser review, 2026-10-08
+
+The issue #180 fixes were checked with computer control against a production Expo
+web export served on loopback. An isolated test server substituted a fake
+`navigator.bluetooth` before app startup; no PC input or real Bluetooth access was
+used. The fixture was outside the shipped app, counted commands without retaining
+their text, and was not included in the export.
+
+- Onboarding, discovery, pairing, profile negotiation, and a mouse click completed.
+- Keyboard Enter cleared live text and returned focus after one Enter command.
+- The visible Enter control also cleared text; fresh typing sent no backspaces.
+- A failed Enter retained text and focus; Retry Enter succeeded without resending
+  chunks or sending backspaces.
+- Draft Enter inserted a newline without increasing the command counts.
+- Reloading exercised a remembered device whose status read never settled. After
+  its three-second budget, fallback selected the fake PC and restored controls.
+  Keyboard Enter continued to work on the new connection.
+
+This is browser UI and fake-transport evidence, not physical Windows/macOS BLE or
+screen-reader certification. The hardware checks above remain required.