[GP-02] Model's declared time/scenario dependency can't be overridden from the system file, and single-axis parameters are capped at one column/row of data

[nikolaredstork]

Affected Component

Expression parsing / grammar (expression/, grammar/)

Type of Change

Minor: bug fix or backward-compatible new feature (e.g. new operator)

Description

A parameter's time/scenario dependency is fixed by the model, and the system file has no real ability to change it — not to loosen it (declare false when the model says true), and not to extend it (add the missing axis on top of what the model declares). Whatever the model declares is effectively the only value that works.

On top of that, whenever a parameter ends up with only one axis of variation (time-only, or scenario-only), its data file is capped at exactly one column or row. There's no way to supply more than one timeseries for it — you just get an error.

How to reproduce

Set a model parameter to scenario_dependent: true in the library.
In the system file, for that parameter, try declaring scenario_dependent: false — this should let you provide one constant/time-only value shared across all scenarios, but it fails.
Now try the opposite: keep the model as-is, but in the system file try to give it more than the model declares (e.g. both time_dependent: true and scenario_dependent: true when the model only declared one of them) — this fails too, with a "data inconsistency" error.
Finally, keep the system file matching the model exactly (say, scenario-only), but point the parameter at a data file with more than one row (more than one timeseries) — this fails as well, with a "expected exactly one row" type error.
What we'd expect instead

The system file should be able to actually configure a parameter's dependency per study, instead of being locked to whatever the model declares. And when a parameter only varies along one axis, it should still be possible to supply more than a single timeseries for it.

Results Impact

Solver output must not change!

Validation Strategy

Results are not expected to change.

Process Checklist

Step 1 — Issue Creation

• Issue created and linked to process GP-02

Step 2 — Triage

• Process confirmed applicable
• Assigned to responsible contributor
• Priority and milestone set (if applicable)

Step 3 — Impact Analysis ⚠️ extended results analysis required

• Affected modules identified
• Results impact explicitly stated: change intended / no change intended
• If results expected to change: before/after difference described and justified
• Breaking vs backward-compatible change determined

Step 4 — Implementation

• Code changes implemented
• Backward compatibility maintained unless explicitly intended as breaking

Step 5 — Testing & Validation

• If results expected to change: reference studies updated with new expected values
• If results must not change: solver equivalence confirmed via tests
• Unit tests cover changed components

Step 6 — CI Validation

• Type checking passes (mypy)
• Formatting passes (black, isort)
• All tests pass in CI (pytest)

Step 7 — Review & Merge

• PR reviewed; documentation changes included

Step 8 — Versioning

• pyproject.toml version bumped

Step 9 — Supporting Files

• AGENTS.md reviewed for impact and updated if needed

Step 10 — Release

• If a release is needed: follow the release process in the Developer Guidelines