I assume "visit" was being used broadly in the sense of "observation", and that a nondeterministic CCD order will still give minor catalog changes?

Possibly relevant are the new DM requirements DMS-REQ-0388, DMS-REQ-0389, and DMS-REQ-0390. These imply that we may need to worry about processing order in operations as well as in CI; see DM-18684.

Following discussion on #dm-middleware, we have the following options for doing this in Gen 3:

1. Have the Jenkins script execute pipetask separately for each visit (can be done now; requires hard-coding the visit IDs for each dataset)
2. Generate a quantum graph for the full dataset, then use command-line tools to break it up into units that can be fed into serial pipetask calls (requires complex scripting, but avoids option 1's need for a "playlist" for each dataset)
3. Implement our own activator that organizes work by visit (Andy Salnikov says this is doable by overriding the scheduler, but that the current activator code isn't quite extensible enough; see DM-24370)
4. instrument the pipeline (DM-21939) with a virtual dataset and/or task that forces association to see the data as "ready" in a specific order

We only need to constrain the order in which DiaPipelineTask's quanta are called, and not any of their dependencies; options 3 and 4 may be able to take advantage of this.

DM-24370 provides a post-processing script for the quanta; all we should need to do is create a subclass that's configured appropriately for ap_verify, then pass it to pipetask.

Looks good, one comment for hash method in mock class.