Release evidence: a compare mode that holds the OS release and exact tools but not the image patch version #79

Problem

The release-runner compare mode needs every job of a profile to report exactly the image identity of the release runner. That includes ImageVersion. The pins mode needs every job of a profile to report one identity between them, which also includes ImageVersion (identity-changed).

GitHub rolls hosted images out in stages. During a roll, one label is served by several image versions at once. A profile with many parallel jobs, such as a sharded mutation table, almost never lands on one image. Then neither mode can pass, and the documented fresh route (re-run at the same commit) does not help.

Seen live on judgment-pack-agent#332. A 28-shard table re-run at the release commit landed on three image versions (21/6/1 shards). The release refused twice with runtime-identity. The five CI jobs matched on the re-run.

Change

Add a third value for profiles.<name>.compare. It is meant for evidence jobs whose result does not depend on the image patch version, given exact tools:

• Tools: every tool of the profile is pinned in pins, and the recorded tools equal the pins exactly. This rule is the same as pins.
• Platform: the platform (ImageOS, RUNNER_OS, RUNNER_ARCH) and the OS-release digest must equal what the release runner resolves for the profile's variant. This keeps "same OS release" a gate, not a hope.
• ImageVersion: recorded and kept in the decision record, but not compared, neither with the release runner nor among the profile's jobs.
• Docs: state plainly what is given up. The jobs may run on different image patch versions, with different preinstalled software outside the pinned tools. This is weaker than release-runner and must be an adopter's explicit choice per profile.
• Mode name: the builder decides it to fit the kit's naming, for example release-os.

release-runner and pins are unchanged. Adopters on earlier kit releases are unaffected until they re-vendor.