Function resolve_up_to_date_fixpoint 

pub fn resolve_up_to_date_fixpoint(
    specs: &[SourceDataBlocksInMemory],
    view_meta: &ViewMetadata,
    block_order: BlockOrder,
    candidates: Vec<PartitionFreshnessRow>,
) -> Result<Vec<bool>, Error>

The pure fixpoint at the heart of find_up_to_date_partitions (see that function’s docs for the derivation): runs spec_is_up_to_date once for every spec against candidates, then drains a worklist of specs that might need re-evaluation because a neighbor newly became stale. Because specs have ascending, non-overlapping insert ranges, a candidate row can be entirely contained in at most two specs’ ranges, and only when those two specs are adjacent in the sorted order (sharing a boundary point, for a degenerate begin == end row) – so the only specs whose verdict can ever change as a consequence of spec i becoming stale are i’s immediate neighbors, index i - 1 and i + 1. A spec is re-evaluated against a candidate set that drops rows entirely contained in some other, currently-stale spec’s insert range (never its own range – a row a spec would itself retire is not evidence about its own freshness); if that recompute still comes back stale, the spec is marked stale (it is never recomputed again – once stale, verdicts are monotone by construction, with no separate clamping step needed) and its own neighbors are pushed onto the worklist in turn. Takes an already-fetched candidates and does no I/O, so analytics/tests/jit_freshness_tests.rs can drive it directly without a live PgPool.