[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._

Start by comparing the bare page.goto calls in the xiaohongshu note.js and download.js adapters with the recovery ladder in clis/google/images.js. Check how the shared page.goto bridge handles navigation failures and whether the existing local nav-retry.js behavior fits there. Done means repeated note and download navigation attempts recover without requiring a fresh window or tab.

Written by the indexing model from the issue text.