Primary Attribute for Score Set Ranges

[bencap]

This pull request introduces a new "primary" flag to score range models and enforces validation to ensure only one score range set is marked as primary. It also adds support for a new Fayer calibration score range schema and updates related test constants and test cases to reflect these changes.

Score Range Model Enhancements:

• Added a primary boolean field to all score range models (ScoreRangesAdminCreate, SavedScoreRanges, and their specialized subclasses), allowing each score range set to be marked as primary. [1] [2] [3] [4] [5] [6] [7]
• Introduced the Fayer calibration score range schema, including its base, modify, create, admin, saved, and combined models, and integrated it into the main score set containers. [1] [2] [3] [4] [5] [6]
• Note that the only time during creation this flag is referenced is in an Admin class. This class is not used in the code base so as not to allow users to submit ranges with the flag applied. However, submission of ranges would overwrite the existing admin class with a new range object without the flag set. Since score sets with ranges are generally published, this shouldn't be an allowed operation anyway. With that said, we should explore solutions that

Validation Logic:

• Implemented a model_validator for SavedScoreSetRanges to ensure that at most one score range set is marked as primary. If none are marked as primary and investigator-provided ranges exist, those are automatically set as primary. Otherwise, a validation error is raised if more than one is marked as primary.

Test Constants and Test Coverage Updates:

• Updated test constants to include the new primary field for all score range test fixtures. [1] [2] [3] [4] [5] [6] [7] [8] [9]
• Enhanced tests to check the correct enforcement of the single-primary rule, including cases with multiple primaries (should error) and with none marked as primary (should default to investigator-provided if present). [1] [2] [3] [4]

These changes improve data integrity for score range sets and expand support for calibration schemas.

[jstone-dev]

Are there other cases where we use validators that have side-effects? Seems like it would be good to separate this logic from the actual validation, though I don't have a good idea about it at the moment.