Emit .var/<spec>.json run records from the Python, Java, Ruby, and Rust ports

[AndreasKoestler]

Follow-up to #66 (run-result format documented as a stable contract in #80).

The Run results reference documents .var/<spec>.json as the language-neutral, machine-readable run record — but today only the TypeScript port emits it (via @oselvar/var-vitest/reporter). The other ports have the SpecResults type (or, in Ruby's case, not even that) but no writer.

Scope

Each port's runner/adapter writes .var/<spec>.json after a run, byte-compatible with the documented format:

• { version: 1, specPath, sourceHash, examples[] } top-level shape (camelCase field names on the wire, whatever the host language's idiom is in-source)
• specPath POSIX-separated, relative to cwd
• sourceHash = hashSource(spec source) — FNV-1a 32-bit over UTF-16 code units, fnv1a: prefix (already ported everywhere; pinned vectors on the reference page)
• Offsets (from/to) as absolute UTF-16 code-unit positions, to exclusive
• JSON serialized with 2-space indent + trailing newline
• Records with failures map through the port's toFailure equivalent (cells only for CellMismatchError, doc only for DocStringMismatchError, neither for ReturnShapeError/plain errors)

Per-port starting points

Port	SpecResults type	Work needed
Python	yes (python/packages/var-core/src/var_core/result.py)	serializer + writer in the pytest/unittest plugins
Java	yes (java/var-core/.../Result.java)	JSON serializer + writer in the JUnit engine / Kotest adapter
Ruby	no type	port the type, then serializer + writer in rspec/minitest adapters
Rust	yes (rust/var-core/src/result.rs, no serde)	serde derives, plus a runner/adapter crate to write files (none exists yet)

Acceptance

• Each port emits a .var/<spec>.json that a consumer (e.g. the LSP) reads interchangeably with a TypeScript-produced record
• Stability rules from the reference page hold: unknown version treated as absent, unknown fields ignored

Note: the conformance corpus deliberately has no run-result goldens (ADR 0002); cross-port byte-identity rests on the shared hash vectors + per-port unit tests. Revisiting that is a separate (ADR-level) discussion, out of scope here.