Add a cot formatter filter

[sharadsw]

Fixes #6253

Adds a filter for including only COs that use the selected COT formatter.

NOTE: This means the results are filtered by formatter name rather than COT name.
If a COT formatter matches the collection's default catalog number formatter, the results will include those COs as well even if they belong to a different COT with no specified catalogNumberFormatName

Checklist

• Self-review the PR after opening it to make sure the changes look good and
  self-explanatory (or properly documented)
• Add automated tests
• Add relevant issue to release milestone
• Add relevant documentation (Tester - Dev)
• Add a reverse migration if a migration is present in the PR

Testing instructions

[melton-jason]

Nice implementation! This does resolve #6253!

Although, I am a little hesitant in always enforcing the filter on the backend.
This change might make it difficult for users to arbitrarily search for Collection Objects which have similar, but different CollectionObjectType catalogNumber formatters.

For example, consider there are two formats, one of NNNN#####, and one ######### where N is a non-incrementing digit and # is an incrementing digit- each of which are invalid against the collection default format, AAA-##### where A is any letter.

With this setup, there is no way for a user to search across all of their "numeric" CollectionObjects without adding a duplicate filter for each numeric formatter, as demonstrated in the below video:

Screen.Recording.2025-02-23.at.11.58.16.PM.mov

This exact setup is probably pretty unlikely, but how likely is the generalization of the problem?
Will users want or expect to generically search across CollectionObjects using catalogNumber without the results being restricted to which field format(s) they used for catalogNumber?

If this is the case, it is somewhat contradictory to the Issue mentioned in #6253 (comment), but I think the problem mentioned above (being too restrictive when filtering) could potentially be just as detrimental as the ones pointed out in #6253 (comment) (being too open when filtering).

If this would be a problem with users, would something like the following solution be sufficient to solve both Issues?
Instead of restricting the results in the backend based on the format name of the catalogNumber filter(s), maybe we could instead add a CollectionObjectType -> Name filter to the query on the frontend whenever the user explicitly chooses a catalogNumber format via the ⚙️ button.

So if the user wants to search on CollectionObjects using the Numeric and ByYear COT catalogNumber formats, we add a COT -> Name -> In filter for each format they select using the ⚙️ button.

That way, we're very clear in letting the user know that the results will be restricted to COs with those COTs, and they still have the option to modify the filter before running the query; so the restriction in filtering by COTs based on the format(s) they're using is still the default, but entirely configurable.

[grantfitzsimmons]

@melton-jason

I agree with your suggestion to add a ⁠CollectionObjectType → Name filter to the frontend query when a user selects a catalog number format is spot on. Users can then have the best of both worlds—they can still choose specific formats while clearly understanding how their results are being filtered. I don't like the idea that we are adding another filter to the query just because they select a format, but if UX feels this is the most intuitive, I am willing to be flexible.

In my view, Jason's approach not only gives users the flexibility they need but also keeps the search process largely intuitive and user-friendly. We just need to make sure our users can easily find what they’re looking for, and Jason's solution seems like a great way to achieve that.