fix(filter)!: apply PreventFilter and PreventSort to every property path

[pdevito3]

Summary

• The parser resolves each property reference with PropertyResolver and checks PreventFilter in arithmetic, on the right side, in a property list, and on the left side. The lookup ignores the letter case.
• A derived property and a custom operation with PreventFilter are checked too.
• SortParser checks PreventSort on the resolved member. Another letter case, or the member name of a property with a query name, is also checked. A derived property with PreventSort is checked too.
• The right-side property and the sort expression are built from the resolved reference.Path, not from the raw text. As a result, the checked property is always the property that QueryKit compares or sorts by.
• A prevented clause obeys IgnoredClauseBehavior (removed by default on v2). A prevented sort is skipped.
• A property list uses the case setting of the resolved member path.

v1.14.2 behavior

PreventFilter was checked only for a left-side member, by its name in the exact case. PreventSort was checked by the typed path in the exact case. A caller could filter or sort by a prevented property in six ways:

Case	Input	Configuration	v1.14.2	This PR
I1	(Age + 0) > 30	Age PreventFilter	filtered by Age	clause ignored
I2	FirstName == Secret	Secret PreventFilter	x => (x.FirstName == x.Secret)	clause ignored
I3	(secret, FirstName) @=* "s"	Secret PreventFilter	filtered by Secret	only FirstName
I4	secret == "s"	Secret PreventFilter, query name hidden	x => (x.Secret == "s")	clause ignored
I5	fullName == "Ann Lee"	derived property with PreventFilter	filtered by the derived value	clause ignored
I6	sort age desc	Age PreventSort, query name years	sorted by Age	sort skipped

A custom operation with PreventFilter was also still applied.

Security risk on v1.14.2

With any of these bypasses, a caller can find the value of a hidden field one comparison at a time, for example (Salary + 0) > 50000, then > 75000. A sort bypass shows the order of the hidden values.

Migration

No setting brings back the old behavior. If a caller needs to filter by a property, remove PreventFilter from it.

Rebase on v2

• The arithmetic check of this PR and the MaxPropertyDepth check of fix(filter)!: apply MaxPropertyDepth to property paths in arithmetic #138 now share one walk, ResolveArithmeticProperties. It returns null for a prevented property, and the parser then ignores the clause. ResolveWithoutDepthCheck is deleted, because arithmetic must obey the depth limit.
• The sort Ingredients.name asc throws SortParsingException, not a NullReferenceException (fix(filter)!: resolve a child collection member in any case #139).

Tests

• Unit PropertyResolverTests: the prevent tests from before fix: restore v1.14.2 behavior for every breaking change on main #134 come back, plus property_on_the_right_side_is_compared_by_its_resolved_path, sort_property_is_sorted_by_its_resolved_path, and sort_on_a_collection_member_path_throws_a_sort_parsing_exception.
• Integration PropertyResolverTests (Postgres): the prevent tests from before fix: restore v1.14.2 behavior for every breaking change on main #134 come back.
• dotnet test: 517 unit tests and 321 Postgres integration tests pass.

Part of #132.