[matt-edmondson]

Fixes #155

What changed

Newtonsoft.Json enforces MaxDepth (default 64) only when reading, so NewtonsoftJsonSerializationProvider.TrySerialize wrote graphs of any depth and returned true, while Deserialize on the same output returned null.

• The settings now carry an explicit MaxDepth = 64, so the reader's limit is stated rather than inherited.
• TrySerialize writes through a private DepthLimitedJsonTextWriter that throws JsonWriterException once an object or array nests past that same limit. The existing catch turns it into false.

Any graph TrySerialize accepts now deserializes back.

Tests

• TrySerialize_DeepChain_SucceedsOnlyWhenItDeserializes with depths 64, 65 and 200: 64 round-trips; 65 and 200 make TrySerialize return false. On main, the 65 and 200 cases fail (serialize returns true).
• Full Essentials.Tests suite on net10.0: 1088 passed. The provider project builds clean on every target.

Note

This and #157 (#154, buffer output until success) touch the same using JsonTextWriter line, so whichever merges second needs a small merge. With both in, a depth failure also leaves the caller's writer empty, as the issue asks.

---

Generated by Claude Code

[matt-edmondson]

ci / .NET / Test on windows-latest failed in PersistenceProviderTests.Concurrent_Stores_To_One_Key_Never_Throw_Or_Hide_The_Key. RetrieveAsync threw UnauthorizedAccessException: Access to the path ...\k.json is denied from AtomicFile.ReadAllTextAsync (Shared/AtomicFile.cs:91).

This failure isn't caused by this PR, which only changes the Newtonsoft serialization provider. The cause is a timing race in persistence code that already exists on main. On Windows, a read that arrives while a concurrent overwriting move has the target pending delete gets ERROR_ACCESS_DENIED instead of a sharing violation. ReadAllTextAsync only retries sharing and lock violations, so this case fails straight away. No fix exists yet; #143 covers the same race on the delete paths, not the read path.

Proposed fix, separate from this PR: in ReadAllTextAsync, also retry UnauthorizedAccessException while the file still exists, so a real permissions problem still surfaces after the retries run out.

I've re-run the failed job once.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud