Hardcoded compiler version strings don't track the release tag #297

Symptom

The OCaml compiler binary's internal version string lags the release tag. Observed on the v0.1.1 release while doing the INT-10 shim closure (#282): the freshly-downloaded v0.1.1 binary still printed:

$ /tmp/affs-cache-v011/affinescript/v0.1.1/affinescript-linux-x64 --version
0.1.0

That's the version baked into the source at tag time, not the tag itself.

Root cause

The string "0.1.0" is hardcoded in six places (grep over bin/, lib/, dune-project):

Nothing in the v* tag pipeline updates any of these — release.yml just runs dune build --release against the source as it is, so the binary's notion of "version" is whatever was last committed by hand.

Suggested fix (sketch — owner decides)

Two clean shapes, both common in OCaml projects:

1. Generate a Version module at build time from dune-project's (version …). dune already has dune-project's version available as a substitution; one canonical Version.value module imported by bin/main.ml, lib/repl.ml, lib/lsp_server.ml, lib/onnx_codegen.ml. Tag-time bump = one edit in dune-project.
2. CI substitution at dune build — the release.yml job edits dune-project (and/or a single header file) to ${GITHUB_REF_NAME} before building. Tag-time bump = automatic, no source change.

(1) is more robust (developers building from a non-release commit get a coherent version); (2) is less invasive but couples versioning to CI.

Severity / urgency

Cosmetic — the shim's checksum-pinned distribution still works correctly, and the LSP doesn't care about the compiler's reported version. But:

• It breaks user trust ("why is my v0.1.1 binary calling itself 0.1.0?").
• ONNX producer_version going into emitted artefacts is a real downstream signal that gets baked into ML models.

Filed as a follow-up while wrapping #282; not blocking that issue's closure.

Refs #282 (closed by #295 — the smoke test there is what surfaced this).