FIBERALLOC-63: Fix collision in science-target constraint names

[monodera]

Summary

makeName("ST", key[0], key[1]) indexed the first two characters of the target-class string rather than elements of a tuple, so every class sharing a two-character prefix produced a single constraint name: sci_P1 through sci_P7 all became ST_s_c.

Impact

The constraints themselves still reached the solver on the supported backends — GurobiProblem.add_constraint does not pass the name to gurobipy, and the HiGHS backend adds every row — so observation counts were not affected. What broke was naming:

• The HiGHS model ended up with seven rows named ST_s_c, making LP/MPS dumps ambiguous and hard to debug.
• LPProblem._constraintdict keeps only the last constraint per colliding name, so constraintByName() cannot retrieve them. This part is latent: constraintByName has no callers today.

Risk

No change to any solution. Row names in dumped models change, so any external tooling that matches on ST_ names should be checked.

Testing

python -m py_compile passes. Naming was checked directly: for ['sci_P1','sci_P2','sci_P7','cal','sky'] the old expression yields 3 unique names out of 5, the new one yields 5 of 5. The solver was not run end to end.

Refs FIBERALLOC-63

🤖 Generated with Claude Code

https://claude.ai/code/session_01CsehUfGABWV8uBhVQWUBet

[Copilot]

Pull request overview

Fixes a constraint-naming bug in buildProblem() where science-target class names were accidentally indexed as strings (taking only the first two characters), causing multiple constraints to collide under the same name and making constraint lookup / model dumps ambiguous.

Changes:

• Update the science-target constraint naming to use the full class key (e.g., ST_sci_P1) instead of ST_s_c.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[mreineck]

Looks great, thank you for spotting this!