core: decide how to version the library, the requirement format and the report format #1

ergo has no version anywhere yet: not on the library, not on the policies people write, and not on the reports it produces. That's fine while it's early, but it needs deciding before anyone depends on it.

There are really three things that change at different speeds, for different people:

Proposal

• Give the library a normal semver version (0.1.0 to start) and put it in the code, e.g. data.ergo.version. Copies of ergo.rego drift away from the repo, so this is the only reliable way to tell which one you're running.
• Version the two formats separately from the library, with a major number only (v1), bumped only when a reader or a policy author would have to change something. A library release that fixes a bug or adds an operator doesn't touch them.
• Put both versions in every report:

  "schema": "…/ergo/report/v1",
  "producer": { "name": "ergo", "version": "0.1.0" }

  schema tells a reader how to read the report. producer tells an auditor which code reached the verdict.
• Let requirements say which format they're written in, so a later library can accept both v1 and v2 during a migration instead of misreading old policies.

To decide

• Hashes. Reports are meant to be hashed. Adding an optional field to the report doesn't break any reader, but it changes the bytes, so the same evidence would hash differently under two library versions. Either we say hashes are only comparable when producer.version matches, or we define a canonical form that stays stable within a report format version.
• Schemas for both formats. Writing each format down as a JSON Schema would make the versions above mean something concrete.
  • The report. The old repo has schema/evidence-report.schema.json (JSON Schema draft 2020-12). It was checked by hand once against two real reports, but no test ever ran it, so nothing kept it in step with the code. It also has a bug: it only allows "every" or "some" for a requirement's require, but the report copies whatever the policy wrote. A requirement with "require": "most" correctly gets a failing $well_formed row, and its report contains "require": "most", so the schema rejects exactly the report that explains a broken policy. Bringing it back means fixing that, giving it a stable $id under a URL we'll keep control of, and adding a CI check that runs real reports against it so it can't drift again.
  • The requirements. There's no schema for the input at all. The closest things are REFERENCE.md and the old markdown editor's TypeScript types, which type a check as "any object". A schema would be new work, but it would let editors help people write requirements and catch typos before a policy runs.
• When. Adding the fields later is harder than adding them before the first release people use.