runtime.version identifies the release, not the bytes

The field says it tells you which build is running. studio-impl's checkpoint
mechanism makes that not quite true: they patch their installed copy from a
committed patch re-applied on install, which is the disciplined form of a practice
this repo has otherwise paid for — declared, reproducible, and it fails the install
rather than half-applying.

But a patched package still reports the version in its manifest. So the field
narrows which RELEASE you are looking at and does not prove the files match it,
and it would be least accurate exactly when it is most used: a bug report from a
box whose shell is not the shell at that SHA.

Stated rather than fixed. Making the runtime hash its own files to detect a patch
would be inventing a guarantee nobody asked for, against a practice that is
legitimate; scoping the claim honestly is what keeps the field credible. Same
reason the consumer-seam guarantee excludes a modified runtime source.

Doc only; 309 tests.

contract/contract-meta.md

@@ -92,6 +92,13 @@ Two schemas sit beside them: `surface-row.schema.json` for a manifest row, and
   because this contract already tells you not to write a version in prose and to
   read it from the thing itself; a remote consumer had no way to do that.
 
+  **It identifies the PACKAGE, not the bytes being served.** A consumer that
+  patches its installed copy — a real and disciplined practice when the patch is a
+  committed file re-applied on install — still reports the unpatched version, because
+  that is what the manifest says. So `runtime.version` narrows *which release* you
+  are looking at; it does not prove the files match it. When a bug report matters,
+  ask whether the install is patched as well.
+
   **It is READ, never typed** — the reference runtime resolves it from the
   `package.json` it ships beside, at boot. `null` is a real answer and means *not
   known*; a runtime that states a version it was told rather than one it read will