docs: Add mYm references and intrinsic versioning explanation

Add references to mYm format documentation:
- MATLAB FileExchange: https://www.mathworks.com/matlabcentral/fileexchange/81208-mym
- GitHub repository: https://github.com/datajoint/mym

Add intrinsic versioning explanation to plugin codecs guide:
- How built-in codecs embed version in data format
- Protocol headers in <blob> (mYm\0, dj0\0)
- NumPy format version in <npy@> headers
- Self-describing structure in <object@>
- Why built-in codecs don't need explicit codec_version field

Clarifies the distinction between built-in codecs (intrinsic versioning)
and plugin codecs (explicit codec_version field).

Author: dimitri-yatsenko

src/explanation/type-system.md

@@ -114,7 +114,9 @@ Codecs provide `encode()`/`decode()` semantics for complex Python objects.
 Stores NumPy arrays, dicts, lists, and other Python objects using DataJoint's custom binary serialization format.
 
 **Serialization format:**
-- **Protocol headers**: `mYm` (MATLAB-compatible) or `dj0` (Python-extended)
+- **Protocol headers**:
+  - `mYm` — MATLAB-compatible format (see [mYm on MATLAB FileExchange](https://www.mathworks.com/matlabcentral/fileexchange/81208-mym) and [mym on GitHub](https://github.com/datajoint/mym))
+  - `dj0` — Python-extended format supporting additional types
 - **Optional compression**: zlib compression for data > 1KB
 - **Type-specific encoding**: Each Python type has a specific serialization code
 - **Version detection**: Protocol header embedded in blob enables format detection

src/how-to/use-plugin-codecs.md

@@ -262,6 +262,17 @@ Plugin codecs evolve over time. Following versioning best practices ensures your
 
 Plugin codecs evolve independently and need to handle data encoded by different plugin versions. Built-in codecs are part of DataJoint's API surface and evolve with the framework itself. When you upgrade DataJoint 2.0 → 3.0, you expect potential breaking changes. When you upgrade a plugin 1.0 → 2.0 while keeping DataJoint 2.0, backward compatibility is critical.
 
+**How built-in codecs handle versioning:**
+
+Built-in formats have **intrinsic versioning** - the format version is embedded in the data itself:
+
+- `<blob>` — Protocol header (`mYm\0` or `dj0\0`) at start of blob
+- `<npy@>` — NumPy format version in `.npy` file header
+- `<object@>` — Self-describing directory structure
+- `<attach>` — Filename + content (format-agnostic)
+
+When DataJoint needs to change a built-in codec's format, it can detect the old format from the embedded version information and handle migration transparently. This is why built-in codecs don't need an explicit `codec_version` field in database metadata.
+
 ### Version Strategy
 
 **Two version numbers matter for plugin codecs:**

src/reference/specs/type-system.md

@@ -503,7 +503,7 @@ Serializes Python objects using DataJoint's custom binary serialization format.
 **Serialization format:**
 
 - **Protocol headers**:
-  - `mYm` — Original MATLAB-compatible format for numeric arrays, structs, cells
+  - `mYm` — Original MATLAB-compatible format for numeric arrays, structs, cells (see [mYm on MATLAB FileExchange](https://www.mathworks.com/matlabcentral/fileexchange/81208-mym) and [mym on GitHub](https://github.com/datajoint/mym))
   - `dj0` — Extended format supporting Python-specific types (UUID, Decimal, datetime, etc.)
 - **Compression**: Automatic zlib compression for data > 1KB
 - **Type codes**: Each Python type has a specific serialization code: