Question: authoritative runtime deployment attestation for replay provenance

[DavinciDreams]

Context

Issue #26 fixed the concrete sf-5/sf-6 mismatch: simulator exports now use the canonical runtime engine version, and the source documents that the version is a compatibility family rather than a unique build identifier.

For replay-backed experiments, one question remains: a public match records engine_version, and /api/health reports the same family, but materially different source/deployment profiles can share that value. From the public record alone, a consumer cannot always map a match or deployment epoch to an immutable source/build snapshot.

There may already be an authoritative deployment audit trail or an established pattern from the infrastructure used for this project or Donto. This issue is intended to discover and document that source of truth, not to assume a new implementation.

Maintainer questions

1. Is an immutable deploy identifier already recorded today—for example a source commit, build/release ID, image digest, or deployment event log?
2. Can that record reliably map a match timestamp or deployment epoch to the code that was running, including rollbacks or multiple workers?
3. Should replay/training consumers use that existing audit trail, or would a stable, non-sensitive identifier be appropriate in /api/health, match metadata, or exports?
4. If a public identifier is desirable, which deployment-provided value is authoritative? We should not guess an environment variable or synthesize an identifier in application code.

Desired outcome

• Document the existing runtime/deployment source of truth, if one exists.
• Clarify whether exact live-deploy attestation is intentionally internal or should be exposed to replay/training consumers.
• If a code change is wanted, identify the authoritative input and expected semantics before implementation.

No combat, balance, or replay-format change is proposed here.