Description

This PR revives the old draft in #7710 and completes the missing test coverage for the new str implementations in flowfilter.py.

The broader goal behind this work is to move filter descriptions to the backend so that mitmweb can eventually stop relying on filt.js. I initially thought that backend descriptions plus the removal of filt.js could be done together in one PR, but after digging into the mitmweb flow I think that second step needs a bit more discussion. For that reason, I’d prefer to merge this first and follow up separately with the mitmweb changes.

One thing to note is that CI currently fails on old-dependencies (https://github.com/mitmproxy/mitmproxy/actions/runs/26331517591/job/77518316616?pr=8245). I guess we can't ignore that, but how should we fix that? never encountered this type of error.

General Discussion for next steps

This PR is only the first step. The remaining open design question is how mitmweb should validate filter expressions once filt.js is removed.

Today mitmweb has three places that use filter expressions:

1. Search
2. Highlight
3. Intercept

Search and Highlight are closely related: they use the websocket flow-filter path and already have dedicated update messages. Intercept is different: it is configured through the /options endpoint.

Because of that, moving validation from the frontend to the backend is not entirely straightforward. The main implementation options I see are:

1. Keep Search and Highlight on the existing websocket filter-update path, and add a separate backend validation path only for Intercept.
   This avoids duplicated work for Search/Highlight, because validation and application are effectively the same operation there.

2. Introduce one unified backend validation channel for all three inputs (Search, Highlight, Intercept), and keep the existing websocket//options paths only for committing valid values.
   This is more uniform conceptually, but it introduces some duplication for Search and Highlight, because the same expression may be parsed once for validation and again for application.

3. Enrich the existing Search/Highlight websocket messages with validation metadata, and extend the /options endpoint so that backend validation errors can be surfaced directly in the UI. The downside is that this changes the semantics of the general options update path, not only the intercept.

Thoughts?

Checklist

• I have updated tests where applicable.
• I have added an entry to the CHANGELOG.