Fix JFile empty-document seed and MString's ZString-source pointer/length mismatch

JFile.cpp: JFile and MFile both "virtual public MString" a single shared
base, so a virtual base is initialized only by the *most derived* class's
constructor. JFile's own constructor never mentions MString, so
JString's own "{}" default initializer never ran - a JFile backed by a
new or nonexistent file started as a raw empty string instead of a valid
empty JSON object. Every subsequent locate()/set() call then silently
misbehaved (no leading "{" for ifNext("{") to match, so writes landed at
offset 0 with no braces or separators - fields ended up prepended in
reverse order, concatenated with no delimiters at all). Fixed by seeding
"{}" via append (matching MFile's own load pattern) whenever the loaded
content is empty.

MString.cpp: several ZString-source copy paths (the ZString/MString copy
constructors, both assignment operators, operator<<(ZString), insert(),
write()) called zstring.getData() (the object's absolute start) paired
with zstring.getLength() (which is documented/implemented as "remaining
bytes from cursor to end", i.e. length - (cursor - data)). Pairing an
absolute start with a cursor-relative length silently corrupts any
cursor-advanced source: the copy starts from the wrong (too-early)
position but is truncated by exactly the amount the cursor had already
advanced, keeping unwanted leading bytes while dropping trailing ones.
Found via the CGIFormData-style resumability testing pattern used
elsewhere this session, triggered by JetCore's new "@name" session
variable feature stripping a sigil prefix via ifNext() before streaming
the remainder into an MString. Fixed by pairing zstring.getCursor()
(cursor-relative start) with zstring.getLength() consistently everywhere
this pattern appeared.

Verified via the existing jstring_test/mstring_test/zstring_test/
parser_test suites (all pass, no output changes) plus a new isolated
JFile round-trip test proving persistence across two separate process
instances sharing one file.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

JFile.cpp

@@ -4,7 +4,20 @@
 
 namespace coreutils {
 
-   JFile::JFile(ZString filename) : MFile(filename) {}
+   // MFile and JString share a single virtual MString base (the diamond:
+   // both "MFile : virtual public MString" and "JString : virtual public
+   // MString"), and a virtual base is initialized only by the *most
+   // derived* class's constructor - so JString's own "{}" default
+   // initializer never runs here. Left alone, a JFile backed by a new or
+   // empty file starts as a raw empty string instead of a valid empty JSON
+   // object, and every subsequent locate()/set() call silently misbehaves
+   // (no leading "{" for ifNext("{") to match, so writes end up inserted
+   // at offset 0 with no braces or separators at all). Detect that case
+   // here and seed valid JSON explicitly.
+   JFile::JFile(ZString filename) : MFile(filename) {
+      if(getLength() == 0)
+	*this << "{}";
+   }
       
    
 }