fix(tui): probe loopback CDP discovery endpoints

[seilk]

What does this PR do?

Fixes #26864.

This fixes default-local TUI /browser connect when the valid Chrome CDP endpoint is bound on IPv6 loopback ([::1]:9222) while IPv4 loopback (127.0.0.1:9222) has a listener that is not a usable CDP discovery endpoint.

The change makes the TUI gateway validate default-local loopback candidates by probing Chrome's CDP discovery endpoints and persisting the first candidate that actually serves /json/version or /json.

Related Issue

Fixes #26864

Related but non-duplicative upstream work checked before opening this PR:

• fix(browser): use 127.0.0.1 instead of localhost for CDP default #10231: switched default from localhost to 127.0.0.1 for IPv6-first localhost failures. This PR handles the inverse case.
• [Bug]: /browser connect can report success on Chrome 144+ built-in Remote debugging while CDP tools still fail #12912 / [Bugfix] Fix local Chrome CDP attach validation #12968: broader local Chrome CDP validation work.
• fix(tui): align /browser connect local CDP handling #17238: TUI /browser connect local CDP handling.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• tui_gateway/server.py
  • Treat ::1 as a default local CDP host.
  • Add default-local loopback candidate probing for 127.0.0.1, ::1, and localhost, preserving the requested host first.
  • Select and persist the first loopback candidate whose /json/version or /json endpoint responds successfully.
• tests/test_tui_gateway_server.py
  • Add regression coverage for the macOS split-listener case where 127.0.0.1:9222 is not CDP but [::1]:9222 is the valid CDP endpoint.
  • Adjust affected expectations so failed explicit localhost connects preserve the requested URL and launch-retry tests still exercise the intended retry path.

How to Test

Reproduction observed before the fix:

1. Start or observe Chrome debugging on port 9222 on macOS.
2. Confirm IPv4 loopback is not the usable CDP endpoint:

   curl -i http://127.0.0.1:9222/json/version
   # HTTP/1.1 404 Not Found

3. Confirm IPv6 loopback is the usable CDP endpoint:

   curl -i 'http://[::1]:9222/json/version'
   # HTTP/1.1 200 OK, includes webSocketDebuggerUrl

4. Run /browser connect through the TUI browser manage path.
5. With this PR, Hermes probes loopback candidates and persists http://[::1]:9222 when that is the working endpoint.

Local validation run:

scripts/run_tests.sh tests/test_tui_gateway_server.py -q -k 'browser_manage_connect'
# 17 passed

scripts/run_tests.sh tests/test_tui_gateway_server.py -q
# 178 passed

git diff --check
# ok

I also ran graphify update . per local repo guidance, but graph visualization generation failed because the graph is too large for HTML output. It did not affect the code/test changes.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 26.4

Note: I ran the targeted TUI gateway suite (178 passed), not the full repository test suite.

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

Observed before fix:

curl -i http://127.0.0.1:9222/json/version
# HTTP/1.1 404 Not Found

curl -i 'http://[::1]:9222/json/version'
# HTTP/1.1 200 OK
# Browser: Chrome/148.0.7778.168
# webSocketDebuggerUrl: ws://[::1]:9222/devtools/browser/...

[teknium1]

Thanks for the focused reproducer and regression test. The split-listener premise remains valid on current main: _browser_connect rewrites default-local URLs to 127.0.0.1:9222 before probing at tui_gateway/server.py:13802-13825, while the TUI uses that default at ui-tui/src/app/slash/commands/ops.ts:161.

Problems

• The submitted launch-retry edit is based on an older contract. Current main uses launch_chrome_debug() plus launch.hint at tui_gateway/server.py:13828-13849; the PR diff uses try_launch_chrome_debug(). A direct application would conflict with current diagnostics behavior.
• Current launch-failure tests intentionally assert normalized 127.0.0.1 output and Chromium-family messaging at tests/test_tui_gateway_server.py:6943-6954, so the stale expectation changes should not be carried forward unchanged.

Suggested changes

• Carry the loopback candidate probing into the current _browser_connect flow while retaining the current launch_chrome_debug result handling.
• Rebase the new IPv6 split-listener regression test on the current browser.manage test block.

Automated hermes-sweeper review.