[autofix] xiaohongshu/note + xiaohongshu/download: UNKNOWN "Navigation rejected"

Summary

OpenCLI autofix repaired these adapters locally, and the retry passed.

Adapter

• Site: xiaohongshu
• Commands: note, download
• OpenCLI version: 1.8.7

Original failure

• Error code: UNKNOWN, message: Navigation rejected.

ok: false
error:
  code: UNKNOWN
  message: Navigation rejected.
  exitCode: 1

Observed behavior (v1.8.7, Chrome extension v1.0.24, daemon v1.8.7):

• Foreground commands fail intermittently under normal pacing — but once a rejection happens, every subsequent attempt fails too (observed 5+ consecutive failures across separate CLI invocations). The bridge never self-recovers on retry; the tab appears stuck until the automation window is closed or a fresh tab is created.
• --window background failed on every observed attempt.
• --trace on succeeded on every observed attempt (3/3), which suggests a timing race inside the bridge navigation path rather than a site-side block (the site was reachable via browser open throughout).
• Manually navigating the bound tab to about:blank did not clear the stuck state; only fresh-window/new-tab navigation did.

Local fix summary

clis/google/images.js already implements a recovery ladder for this exact error (navigateGoogleImages: closeWindow → retry goto → newTab + setActivePage), but the xiaohongshu adapters call bare page.goto(...).

Added the same ladder as a shared gotoRobust() helper locally (~/.opencli/clis/xiaohongshu/nav-retry.js) and wired it into note.js and download.js in place of the bare page.goto(...) calls.

Verification: note went from 0/4 to 4/4 back-to-back successes, a download that had failed 3× recovered on the patched path, and a 168-note batch job (note + download per note) has since run to completion of 19+ notes with zero navigation rejections.

Suggestion

Consider hoisting this recovery ladder into the shared page.goto bridge implementation (or a default wrapper for COOKIE/UI strategies) so every adapter benefits, instead of each adapter re-implementing it — google/images currently carries the only copy.

Issue filed by OpenCLI autofix after a verified local repair.