Tag ambiguous strings as string and keep JSON null in nested Loro values

[joepio]

Before: a string property whose value starts with [, {, atomic:, did:ad: or http(s):// was stored untagged, and readers guessed its type, so ["track","osc"] came back as a nested resource and https://example.com as a URL. JSON null inside nested maps and lists was silently dropped on write.

After: such strings get the string tag in the Loro datatypes map and read back as plain strings in Rust and TS. JSON null survives a round trip in nested maps and lists.

This is the one part of #2045 (frozen app schemas) that #2151 did not carry over, and it affects all data, not only schemas. Atomic Audio relies on it, because it uses JSON-array strings as entity IDs.

How: datatype_tag (Rust) and datatypeTag (TS) tag ambiguous strings, and atomic_value_from_tag reads the tag. The Rust json_value_to_loro_* helpers and the TS writeJsonToLoroMap/List write null instead of skipping it. Older readers don't know the string tag and fall back to their old guess, which is no worse than today.

Related Issues

Part of #2045, which #2151 replaced.

Checklist

• Add changelog entry linking to issue, describe API changes
• Add or update tests if needed (Rust: ambiguous_strings_preserve_their_declared_type, json_null_is_preserved_in_nested_maps_and_lists; TS: datatypes.test.ts, a pushListItem null test that fails without the fix)
• Update docs if needed

Local: atomic_lib lib tests 774 passed, atomic-server lib tests 386 passed, @tomic/lib 1516 passed.

---

Generated by Claude Code

[joepio]

Complexity and compatibility review (+87/-6 over 6 files; I read the diff, not the surrounding reader code or the signing path). Since this touches how all new values are written, I'd hold the merge for items 1 and 2.

1. The "ambiguous string" rule exists twice and the copies already differ. Rust datatype_tag (lib/src/loro.rs ~918-928, via is_atomic_identifier) excludes atomic://; the TS regex in browser/lib/src/datatypes.ts (~79-83) tags atomic: followed by anything, including atomic://. So the tag written depends on which side wrote the value. Use atomic:(?!//) in TS, and put the examples in one shared fixture list that both the Rust and TS tests read; nothing tests parity today.
2. Backward compatibility is claimed, not shown. Old stored documents go through the unchanged fallback, so they should materialize identically, but there is no test with an old untagged snapshot. Newly written commits carry extra datatypes entries and Null ops, and I have not seen evidence that released readers (older Rust/WASM/TS) ignore an unknown string tag and tolerate null inside nested maps and lists. A compat test that feeds a post-PR delta to a pre-PR reader build is the cheapest check; given the standing rule that old clients keep working, I would want that before this lands.
3. TS has no test that a ["a","b"] string carrying the string tag reads back as a plain string; the TS tests only cover the tag function and the write side.

The rest is proportionate: null handling is a one-line arm in each helper and no new layers are added.

---

Generated by Claude Code

[joepio]

Both holds are addressed in 5d36809.

1. atomic://: Rust was right. The untagged reader (loro_value_to_atomic_value) leaves atomic://x as a plain string because is_atomic_identifier excludes it, so nothing needs pinning. TS now uses atomic:(?!\/\/). Both sides test against one fixture, lib/test_files/string-datatype-tags.json (17 cases), read by string_datatype_tag_matches_shared_fixture in Rust and by datatypes.test.ts.
2. Backward compatibility:
   • An old untagged snapshot still materializes through the heuristic as before.
   • An unknown tag falls back to the heuristic without an error. On develop, atomic_value_from_tag ends in _ => None and the caller falls through, so this is the path a pre-PR reader takes on the new string tag.
   • Null in nested maps and lists reads without error. loro_value_to_json and loro_value_to_atomic_value are unchanged from develop, so this also covers old readers.
   • TS has the same tests for an unknown tag and for nested Null.

Locally: loro tests 64 passed, clippy -D warnings clean, @tomic/lib 1533 passed, lint clean.

---

Generated by Claude Code

[joepio]

Run 5206 failed on c670647 because atomic_lib (lib test) did not compile. include_str! could not read browser/lib/src/string_datatype_tags.json, since the Dagger Rust container does not mount that file. This PR caused it.

Fixed in fee0236: the fixture now lives in lib/tests/fixtures/string-datatype-tags.json. That is where the other shared Rust/TS fixtures live (class constraints, JSON Schema interop), and both the Rust container and the lib unit-test container mount it. Locally the Rust fixture test, datatypes.test.ts (20) and lint pass.

---

Generated by Claude Code