expose engine version to scripts and via --version

## Problem

A script cannot learn which engine is running it: the `esto` binary takes no `--version` flag, and no version is exposed to the JS runtime.

This matters for reconcilers that cache work keyed on "everything that can influence the output". A static-site build skips re-rendering a page when the hash of its inputs matches a recorded value; the input set includes the page source, the builder's own code — and the engine, since an esto/optative-script upgrade can change output bytes (transform behavior, builtin semantics) without any user file changing. Today the engine is the one input that cannot be captured, so an engine upgrade silently fails to invalidate anything.

## Proposal

Either or both (each is a few lines):

1. `esto --version` / `esto -V` — clap's version flag, so wrappers can capture it.
2. Expose it in the runtime, e.g. an `esto` module export (`import { version } from 'esto'`) carrying `CARGO_PKG_VERSION` of the CLI plus the versions of `optative-script`/`optative-script-mdx` it was built with — scripts can then mix it into their cache keys directly, which is more robust than shelling out.

## Motivating consumer

Incremental static site builder: every page's signature would include `engine: ` so an esto upgrade rebuilds the world exactly once, instead of never.

Locate the esto CLI entry point and the JavaScript runtime module, then inspect how the package version is currently defined for the binary and its dependencies. Verify the chosen interface by running esto --version or -V and by loading the runtime export from a script. Done means scripts can reliably obtain the engine version needed for cache keys.

Written by the indexing model from the issue text.