fix(mongoc): a negated q on a sub-attribute path matched Entities without it

[kzangeli]

q=a.b.c!=1 returned Entities that have no a.b.c at all — under mongoc only, which pushes q into the database, while corDB walks the Entity in the broker (ldEntityMatch.c) and answered correctly all along.

The backend contradicted itself

Over a fixture that truncates the path at every depth — E1 a.b.c=1, E2 a.b.c=2, E3 a.b (no c), E4 a (no b), E5 no a:

query	mongoc, before	corDB	§ 4.9
q=a.b.c==1	E1	E1	E1
q=a.b.c!=1	E2, E3, E4	E2	E2
q=a.b.c!=99	E1, E2, E3, E4	E1, E2	E1, E2
q=a.b.c	E1, E2	E1, E2	E1, E2
q=!a.b.c	E3, E4, E5	E3, E4, E5	E3, E4, E5

q=!a.b.c correctly reports E3 and E4 as not having the path, while q=a.b.c!=1 simultaneously reports their a.b.c as unequal to 1. That is a contradiction inside one backend, not a difference of interpretation.

§ 4.9 settles the reading anyway: a term over an attrPath the Entity does not have evaluates to false. An Entity with no a.b.c does not "have a value different from 1".

Cause

In the multi-instance $expr builder — and the comment above it already states the correct rule:

EVERY instance must satisfy != / notPattern, i.e. none satisfies the positive form — but the Attribute must still be present, since an Entity without it does not "have a value different from X".

It enforces that with {"$type":"$<attrPath>"} == "object", which checks the attribute and says nothing about the rest of the path. For a.b.c, E3 holds a, passes the guard, and then $not over a missing field is true. E5 was excluded only because it lacks a — the guard working at the one depth it covers.

Fix

Add the guard the comment intends: the full per-instance expression — sub-path, value and value-path included — must resolve in at least one instance before the negation applies. At depth 0 it costs nothing, since a stored Attribute always has its value, which is why the existing tests never saw this.

The test is an oracle, and it was free

query_q_deep_path_negated.test declares no REQUIRE_DB, so the harness already runs it against both backends — and they evaluate q in completely different places. Any future divergence between the pushdown and the in-broker matcher fails one of the two suite runs on its own, with no special machinery.

Deep attrPaths were tested before this, but only with == and >. The negated operators are exactly where a pushdown and an in-broker walk part company, because Mongo's $ne / $nin / $not also match a missing field.

Found by following up the attrInstanceOf entry in the never-entered bucket — zero under mongoc, covered under corDB — which is what flagged the two implementations as never having been compared.

Verification: 635/635 mongoc, 585/585 corDB. Both backends now produce byte-identical output against one set of expects.