Add L1 regularisation to dispatch

[tsmbland]

Description

Please include a summary of the change and which issue is fixed (if any). Please also
include relevant motivation and context. List any dependencies that are required for
this change.

Fixes # (issue)

Type of change

• Bug fix (non-breaking change to fix an issue)
• New feature (non-breaking change to add functionality)
• Refactoring (non-breaking, non-functional change to improve maintainability)
• Optimization (non-breaking change to speed up the code)
• Breaking change (whatever its nature)
• Documentation (improve or add documentation)

Key checklist

• All tests pass: $ cargo test
• The documentation builds and looks OK: $ cargo doc
• Update release notes for the latest release if this PR adds a new feature or fixes a bug
  present in the previous release

Further checks

• Code is commented, particularly in hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[Copilot]

🟡 Not ready to approve

The new parameter’s Rust default value and the secondary-objective scaling currently don’t match the documented “small mean deviation” behaviour and can materially distort dispatch outcomes.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Pull request overview

This PR introduces an optional secondary objective in the dispatch optimisation to regularise asset activity (L1 deviation in utilisation fraction) so dispatch is spread more evenly across otherwise-equivalent assets, controlled by a new model parameter exposed in the input schema.

Changes:

• Adds an activity-equalisation (L1) penalty term to the dispatch optimisation when dispatch_activity_equalisation_epsilon > 0.
• Introduces dispatch_activity_equalisation_epsilon to ModelParameters with validation and a default value.
• Exposes the new parameter in the input model schema (schemas/input/model.yaml).

File summaries

File	Description
src/simulation/optimisation.rs	Adds secondary-objective variables/constraints to penalise utilisation deviations across assets/time-slices.
src/model/parameters.rs	Adds a new parameter to control the regularisation strength (incl. default + validation).
schemas/input/model.yaml	Documents and exposes the new parameter to user configuration with a default and notes.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 2
• Review effort level: Low

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[alexdewar]

I've had a look through and it seems sensible enough. I was hoping to have a bit of a play with it but ran out of time in the end.

I think we should pick a sensible default value for this and make users set please_give_me_broken_results to either change it or reduce it below this default value, because it will lead to potentially non-intuitive results (e.g. varying arbitrarily between platforms and versions of HiGHS). Of course, users might want to disable it for performance reasons, but that's on them 👅. We should just make it clear that the "supported" configuration is with an appropriate amount of regularisation.