fix(xiaohongshu): accept stacked duplicate filter chips in the search panel

[yisiliu]

Problem

xiaohongshu search currently fails on every invocation with:

COMMAND_EXEC: Xiaohongshu search filter layout did not match the expected visible panel (ambiguous_option).

Inspecting the live search_result page shows why: the current layout renders every filter chip twice inside the same .tag-container, both copies passing the visibility check, at pixel-identical bounding rects (verified: two 最新 chips both at {x:936, y:187, 96×40}, same parent chain). findOption requires exactly one visible text match per group, so filter application — which runs for all five groups even at defaults — dies on the first group.

Fix

Matches whose bounding rects are identical are one visual control stacked on itself, not an ambiguity: dedupe them and click through (preferring the copy carrying .active, so the activation wait-loop and the final verification see the active state regardless of which clone the site marks). Matches at distinct positions still fail closed as ambiguous_option — the fail-closed contract from #1506-era layout drift is preserved, and the test fixture now places the second copy of a genuinely ambiguous chip at a different rect to keep that path covered.

Verification

• New JSDOM test mirrors the live layout (every chip duplicated at identical rects) and asserts a --sort latest run succeeds end-to-end; written test-first against the real filter script.
• Existing distinct-rect ambiguity test still rejects with ambiguous_option (65 search tests, 341 xiaohongshu adapter tests, 24 rednote tests — all green; full suite 7317 passed, typecheck and both lint gates clean).
• Live against www.xiaohongshu.com (logged in): default-filter search returns results in 2.7s; --sort latest, which clicks a deduplicated chip, applies and returns latest-sorted results in 4.8s.

🤖 Generated with Claude Code

---

Part of the xiaohongshu risk-control/persistence arc — umbrella issue with full motivation and cross-PR context: #2470