fix(client-engine-runtime): parameterize primitive values of Json fields - #30861

Problem

A string, number or boolean written to a Json field is never replaced by a placeholder, so the literal stays in the query plan cache key. Every distinct value compiles a new plan and adds its own cache entry. With large string payloads the cache fills up to queryPlanCacheMaxSize entries that each hold the value, which is the memory growth reported in the issue. #handlePrimitive returns early when matchesPrimitiveMask fails, and that check has no case for the Json bit, so the JSON.stringify branch below it never runs for a Json-only field.

Change

Primitives on an edge whose mask includes Json are now stringified and given a Json placeholder before the primitive type check, the same way #handleObject and #handleArray already treat objects and arrays. The gt/gte/lt/lte Json filters are left as literals, because the query compiler reads their value to pick the JSON type to compare against and panics on a placeholder there.

Tests

Unit tests in scalar-values.test.ts (with a Json field added to the fixture schema) check that a string and a number in the same Json field share one parameterized query, and that Json comparison filters keep their literal. Functional tests: a primitive values case in json-fields, and a where path gt case in 0-legacy-ports/json for postgres and mysql. The Json functional suites pass on better-sqlite3, pg and mariadb.

Fixes #30859

Summary by CodeRabbit

• Bug Fixes
  • Fixed handling of primitive values in JSON fields so strings, numbers, decimals, and booleans retain their correct JSON types when stored.
  • Fixed JSON-path greater-than comparisons for string values so matching records can be returned correctly.
  • JSON comparison filters using greater-than or less-than operators now preserve their comparison values without converting them into query parameters.