Clarify the default values for newly created LiveMap and LiveCounter

[sacOO7]

• Based on Clarify the default values for newly created LiveMap and LiveCounter in RTLM4 and RTLC4 #361
• Remove the term "zero-value" object as it is an unnecessary detail that simply describes a newly created object according to RTLM4 and RTLC4

[sacOO7]

I had a question

1. We already have zero-value references in the codebase ( both ably-js and ably-java AFAIK), so do we want to keep existing terminology or adapt to new one?
2. If we adapt to new one ( default value or a new object ), do we also need to update relevant references in all codebases. If we keep implementation spec-agnostic, then it will differ across SDKs for zero-value objects
3. Maybe replacing zero-value object with empty object would make more sense?

[sacOO7]

I had a question

1. We already have zero-value references in the codebase ( both ably-js and ably-java AFAIK), so do we want to keep existing terminology or adapt to new one?
2. If we adapt to new one ( default value or a new object ), do we also need to update relevant references in all codebases. If we keep implementation spec-agnostic, then it will differ across SDKs for zero-value objects
3. Maybe replacing zero-value object with empty object would make more sense?

Validated all public facing liveobject docs for zero-value, zero value terminology

We found =>

The "zero-value" terminology is purely a spec-internal artefact that was never surfaced in public-facing documentation. The docs already use the user-friendly phrasings ("empty map", "initial value 0", "newly created object", "initial state") that the spec PR is migrating toward, so the public surface is already coherent with the new wording.

ZERO_VALUE_LIVEOBJECTS_REVIEW.md