perf: expression equality rehashes a constant keyword for every entity row #774

A query that compares an entity/ref with a keyword literal resolves the same keyword again for every input row:

[:find ?f :where [?f :name ?n] [(= ?f :p5)]]

On the #394 envelope fixture, ?f is an entity ref. Expression evaluation runs once per row, and expr_eq clones :p5 and computes its UUID v5 on each keyword/ref comparison. This affects != and either operand order too.

Verified on v3 at d0ad89c1d (unchanged from the source audited for #531):

• engine/filter.rs:155–173: evaluates expressions over individual rows.
• datalog/executor.rs:627–634: expr_eq calls edn_to_entity_id(&EdnValue::Keyword(k.clone())) for a keyword/ref pair.

This expression path was added by #744. It is separate from #531's old PatternMatcher::match_component path, removed by #551 and verified in #773. Pattern entity/value keyword constants already resolve while planning. The merged audit and benchmark report records this follow-up's source evidence.

Performance impact is unmeasured. The #531 profiles did not exercise keyword/ref expression equality, and expression evaluation also allocates a binding HashMap per row. Do not attribute the old matcher's historical 8% cost to this path.

Next steps:

• Measure a keyword/ref equality workload on the idle bench machine before choosing a milestone or implementation.
• Assess resolving literal keyword/entity equivalence once per query, or reusing the engine's ID cache, without an unbounded/global cache or new dependency.
• Preserve An expression = / != does not equate a keyword with a ref to the entity it names #744 semantics for =, !=, both operand orders, dynamic operands and prepared slots; include nested/rule expression paths when evaluating a fix.

Also present in v2.0.11. This is a performance issue, not a data-integrity bug; no v2.x backport under the support policy.