Science-target constraint names collide across target classes in buildProblem

Problem

In ets_fiber_assigner/netflow.py, buildProblem() names the "observed or
sink" constraint for each science target class like this (line 628):

for key, val in STC_o.items():                          # line 624
    ...
    prob.add_constraint(makeName("ST", key[0], key[1]),
                        prob.sum([v for v in val]) == n_obs)

The keys of STC_o are plain target-class strings (TC = tgt.targetclass,
line 458), so key[0] and key[1] are the first two characters of the
class name, not tuple elements. Every class sharing a two-character prefix
collapses onto a single name: with the classdict used in the demos, sci_P1
through sci_P7 all produce ST_s_c.

Impact

The constraints themselves are all handed to the solver correctly on the
supported backends – GurobiProblem.add_constraint does not pass the name to
gurobipy, and the HiGHS backend adds every row – so observation counts are
not affected. What breaks is naming:

• The HiGHS model ends up with seven rows named ST_s_c, which makes 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.

Proposed fix

prob.add_constraint(makeName("ST", key), ...)

Risk

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