macOS: ax_navigate_browser has no callers — and AXPress is the layout-proof BrowserBack

### What

`openlogi_inject::ax_navigate_browser` (added in #363 for Safari) is never called anywhere in the workspace. The comments in `inject/macos.rs` ("Safari is handled upstream via ax_navigate_browser() with the PID captured at press time") and around the BrowserBack dispatch in `runtime.rs` still describe that upstream AX path, so the wiring looks orphaned by the plan-driven capture refactor (#419).

### Why it matters beyond dead code

`BrowserBack`/`BrowserForward` post a fixed US-ANSI chord (`kVK_ANSI_LeftBracket`). On layouts where the localized menu equivalent differs, the chord does nothing — confirmed on Spanish ISO in #1263's comments, where Safari's *History → Back* is ⌘Ñ. `AXPress` on the app's actual menu item — what this function was built to do — is layout-independent.

### Proposal

Either wire it back in as the primary macOS path for `BrowserBack`/`BrowserForward` (chord as fallback when AX fails), or delete the function and its comments. `.claude/rules/objc-ffi.md` already earmarks this code for `objc2-application-services` when touched.

Refs #363, #419, #1263

Start by tracing BrowserBack and BrowserForward in runtime.rs and the related comments and ax_navigate_browser implementation in inject/macos.rs; read .claude/rules/objc-ffi.md before changing the macOS FFI. The work is complete when the AXPress path is wired with the chord as fallback, or the orphaned function and comments are removed, and layout-dependent browser navigation is addressed.

Written by the indexing model from the issue text.