Stop pgjsonb purge / archive from orphaning recent salt_returns rows

[co-cy]

Depends on #69049. This branch is layered on top of that PR; the diff currently shows both commits and will rebase to a single commit once #69049 is merged.

What does this PR do?

_purge_jobs and _archive_jobs decided which jids rows to handle with this predicate:

delete from jids where jid in (
    select distinct jid from salt_returns where alter_time < %s
)

The subquery returned a jid as soon as any single salt_returns row for that jid was older than the cutoff. For long-running jobs whose minions answer at staggered times — slow orchestrate runs, SSH commands that take hours, syndic batches — the predicate fired on the first old return and deleted the parent jids row, but the recent salt_returns rows for the same jid stayed behind. They became orphans: salt-run jobs.lookup_jid could no longer rebuild the load, the archive held parent rows without their recent returns, and any code joining salt_returns to jids saw a broken parent edge.

This PR rewrites both predicates as an EXISTS / NOT EXISTS antijoin so a jids row is removed only when every salt_returns row for that jid is older than the cutoff:

delete from jids j where exists (
    select 1 from salt_returns r where r.jid = j.jid
) and not exists (
    select 1 from salt_returns r
    where r.jid = j.jid and r.alter_time >= %s
)

EXISTS is preferred over IN (SELECT distinct ...): it short-circuits on the first hit, uses idx_salt_returns_jid for per-row probes, and avoids NOT IN's NULL gotcha. Since jids is typically much smaller than salt_returns, the planner picks an antijoin via the jid index — at least as fast as the original seq scan under the old predicate.

What issues does this PR fix or reference?

Fixes #69060

Previous Behavior

A long-running job whose first minion answers at t0 and last minion answers at t0 + keep_jobs_seconds + ε loses its jids row at the first maintenance tick after t0 + keep_jobs_seconds, while the late return is still being inserted into salt_returns. Subsequent jobs.lookup_jid calls cannot reconstruct the load.

New Behavior

The parent jids row is kept while any recent salt_returns row for that jid exists. Once every return is older than the cutoff, the parent and the returns are purged together, and the archive captures both consistently.

Scope of this PR

Fixes orphan returns only. There is a related but separate slower leak: jobs published against an offline target leave a jids row with no salt_returns rows at all, which the maintenance loop never touches because the subquery cannot match on missing data. Closing that needs either a jids.created_at schema migration with backwards-compat detection in the code, or jid-format parsing in Python. Both warrant their own discussion and will be tracked as a follow-up.

Merge requirements satisfied?

• Docs (no schema or user-facing config change; not required)
• Changelog — changelog/69060.fixed.md
• Tests written/updated — see tests/pytests/unit/returners/test_pgjsonb.py:
  • test__purge_jobs_keeps_jids_with_any_recent_salt_returns_row
  • test__archive_jobs_keeps_jids_with_any_recent_salt_returns_row

Commits signed with GPG?

No.