[tmm]

Option (c), approved by tmm: iterative JSON code plus a lower nesting limit, with the limit documented as a difference from JS.

What changed:

• JSONParser is one loop with an explicit stack. Key order, duplicate-key handling, and error messages and offsets are unchanged.
• JSONSerializer.write, JSONValue.hash, QueryHash value hashing and JSONValue.== don't recurse. == recurses for the first 64 levels and switches to an explicit stack below that.
• JSONParser.maxDepth drops from 5,000 to 1,500. Freeing a value still recurses, in Array's and JSONObject's storage. At 1,500 levels that fits a 512 KB stack in a release build.
  • Measured on a 512 KB thread: a release build frees arrays and objects to at least 3,000 levels. A debug build frees arrays to 2,000 levels, but only objects to about 1,000.
• JSParity.md documents the limit. JS has no limit short of its own stack, and zero-cache writes about 4,100 levels. A row whose JSON column is nested deeper than about 1,495 levels makes the client reject the poke, disconnect, and hit the same row after reconnecting. Real data, such as rich text, rarely passes a few hundred levels.

Tests:

• JSONDepthTests checks values exactly maxDepth deep on a 512 KB thread. On the old code it crashes with signal 11.
• SweepWireTests.deepRowValue checks a poke at the limit on 512 KB, including freeing it, and checks that one more level is rejected.

Cost (release, same process, old vs new):

• Parsing a poke: +7–9%.
• Parsing payloads with many nested containers: +12–22%.
• == on large nested values: +35–40%.
• Client benchmarks: no change outside noise.

Tested: 209 tests pass under ulimit -s 512. Also lint, ClientE2ETests (2) and the zbugs-swift build.