Task/rdmp 360 catalogue status change behaviour

[JFriel]

Proposed Change

When a catalogue is marked as project specific, prevent it fro mbeing used in cohort builds.
This PR is around the execution on non-project CICs that already have the catalogue in the CIC build

Type of change

What types of changes does your code introduce? Tick all that apply.

• Bugfix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that would cause existing functionality to not work as expected)
• Documentation-Only Update
• Other (if none of the other choices apply)

Checklist

By opening this PR, I confirm that I have:

• Ensured that the PR branch is in sync with the target branch (i.e. it is automatically merge-able)
• Created or updated any tests if relevant
• Have validated this change against the Test Plan
• Requested a review by one of the repository maintainers
• Have written new documentation or updated existing documentation to detail any new or updated functionality and how to use it
• Have added an entry into the changelog

In general, to fix a "Missed 'readonly' opportunity" on a field, you add the readonly modifier to the field declaration, provided that all assignments to the field occur either at the declaration or within constructors of the same class, and there are no other writes (e.g., in methods, properties, or external code via ref).

Here, the best fix is to change the declaration of _activator on line 80 from private IBasicActivateItems _activator; to private readonly IBasicActivateItems _activator;. This preserves existing behavior because the field is still assigned in the constructor and read elsewhere; it only prevents any future non-constructor code from reassigning _activator. No additional imports, methods, or other definitions are required, as readonly is a built-in C# modifier and we are not altering how _activator is used.

Concretely:

• In Rdmp.Core/CohortCreation/Execution/CohortCompiler.cs, locate the field declaration around line 80.
• Replace private IBasicActivateItems _activator; with private readonly IBasicActivateItems _activator;.
• No other lines in the provided snippet need to be changed.

To fix the issue, the field should be declared with the readonly modifier so it cannot be reassigned after object construction. This preserves current functionality because readonly still allows assignments at declaration and in any constructor of the same class, which covers the two existing assignments we see.

Concretely, in Rdmp.UI/SubComponents/CohortIdentificationConfigurationUI.cs, update the field declaration at line 76 from private CohortIdentificationConfigurationUICommon Common = new(null); to private readonly CohortIdentificationConfigurationUICommon Common = new(null);. No other code needs to change: the assignment in the constructor remains legal because readonly fields can be set in constructors. No new imports or helper methods are required.

To fix this, we should add the readonly modifier to the Common field declaration so that it cannot be reassigned after the constructor finishes. This keeps current behavior—mutating properties on the CohortIdentificationConfigurationUICommon instance remains fully allowed—while preventing unintended reassignment of Common to a different instance.

Concretely, in Tools/rdmp/CommandLine/Gui/ConsoleGuiCohortIdentificationConfigurationUI.cs, change the field declaration at line 26 from:

private CohortIdentificationConfigurationUICommon Common = new (null);

to:

private readonly CohortIdentificationConfigurationUICommon Common = new (null);

No additional methods, imports, or other definitions are required; this is a local modifier change on the existing field and will not alter any external behavior aside from disallowing reassignment of Common within this class.