Compare two stored versions of a rule in your organization.

Both versions must exist on the same rule and the rule must belong to your
session organization; otherwise a 404 naming the missing side is returned. Use
GET /rules/{rule_id}/versions to discover which version numbers exist.

Only atomic_sql and scheduled_sql rules can be compared, since the comparison
reads SQL; other rule types return 400.

field_diff carries the exact differences computed here — schedule, throttle,
severity, entities, tags, bind params — and is always populated. The five analysis
fields (query_logic_*, *_data_coverage) are judged by hunt-api. That call is
informational and fails open: if hunt-api errors or times out, those five fields
come back null and the rest of the response is unaffected.

When the two versions carry byte-identical SQL — including
start_version == end_version, which is allowed — the comparison is answered
without a model call: query_logic_summary and query_logic_assessment say
the logic is unchanged, query_logic_assessment_level is info, and only
*_data_coverage is null. So a null coverage pair alongside a populated summary
means "no query change", where all five null means the call did not answer.

The versions may be passed in either order; start_version above end_version
is a supported request and reads as "what would reverting look like". The
analysis describes the start → end transition as given.

On both rule payloads, created_at is that version's timestamp rather than the
rule's, so the two sides are comparable; every other rule endpoint reports the
rule's own created_at.