A filter language, in Core, so the three front-ends cannot disagree about it

[Hawkynt]

Implements PRD §56 — field:value with comparisons, quoted strings, booleans, regex and unit-aware quantities — and the requirement that the same syntax work in GUI, TUI and CLI.

procman --filter 'cpu:>50 AND user:alice'
procman --filter 'memory:>1GiB NOT name:chrome'
procman --filter 'name:/^kworker/'

ProcessQuery lives in ProcessManager.Core; every front-end filters through ProcessView.TextFilter, so no front-end has its own dialect.

The registry made this cheap

Every field already had a stable key, a declared kind and a declared unit, so every field became filterable without being mentioned in the parser:

• Kind decides the comparison. pid:1234 is numeric because a pid is an identifier; name:1234 is text because a name is text. Both look like digits.
• Unit decides the arithmetic. 1G is 1073741824 against a byte field and 1000000000 against a count. That is a 7.4% error if conflated, and they are different questions. GiB/GB overrides the guess.

Two deliberate behaviours

• A half-typed query degrades to substring search rather than matching nothing — somebody typing chrome: is midway through a working query, and blanking the list at every keystroke makes the box unusable. --filter does the opposite and refuses with the reason, because a script that silently matched nothing is worse than one that stopped.
• An unknown value matches no comparison at all — not > 0, not == 0, not != 5. Claiming a process's memory is "not equal to 5" is a claim about a number we do not have (§72.3).

--help-fields

Prints every field, its aliases, per-platform notes and the grammar — generated from the registry. The old --sort help listed ten keys when there were seventeen, which is what a hand-kept list does.

Bugs the tests caught

Three, all in the parser, all fixed here:

1. || was not a stop condition for the implicit-AND loop, so a || b parsed as a AND "||" AND b — the OR silently became an AND of two nonsense terms.
2. An operator separated from its field by spaces (threads > 1) read as a free-text search for the word "threads".
3. A keyword check that would have made ORacle into an OR followed by acle.

One test expectation of mine was also wrong rather than the code, and is corrected.

Verification

• 209 tests (51 new), both UTF-8 and C locales
• --self-test 25/25 · benchmarks within budget · golden frame unchanged