cuOptCreateProblem fails on num_constraints=0 (zero-row problems)

Summary

cuOptCreateProblem fails with CUOPT_INVALID_ARGUMENT for any problem with zero linear constraints — including pure bound-constrained LPs and QCQP-style problems (quadratic constraints only, no linear rows).

Repro (Java, but this is a C API issue)

try (Problem problem = new Problem("no-constraint")) {
  Variable x = problem.addVariable(0.0, 10.0, 1.0, VariableType.CONTINUOUS, "x");
  problem.setObjective(x, ObjectiveSense.MINIMIZE);
  try (Solution solution = problem.solve()) {  // throws here
    System.out.println(solution.getTerminationStatus());
  }
}

Exception in thread "main" com.nvidia.cuopt.mathematicaloptimization.CuOptException: cuOptCreateProblem failed with status 1
	at com.nvidia.cuopt.mathematicaloptimization.NativeCuOpt.createProblem(Native Method)
	...

Same failure with any zero-linear-constraint problem, e.g. a QuadraticExpression constraint with no linear rows, or a single SEMI_CONTINUOUS variable with no addConstraint calls at all.

Root cause (traced, not fixed)

cuOptCreateProblem (cpp/src/pdlp/cuopt_c.cpp:338) has no explicit num_constraints <= 0 check itself — unlike sibling functions such as cuOptSetInitialDualSolution, which does. The failure comes from a raft::exception thrown somewhere inside problem->set_csr_constraint_matrix(...) (or a related setter) on a zero-row CSR matrix, caught and converted to CUOPT_INVALID_ARGUMENT. Not traced further than that.

Why this looks unintentional

• No explicit validation rejects it at the API boundary (contrast with the num_constraints <= 0 check present elsewhere in the same file).
• Pure bound-constrained LPs and quadratic-only-constrained problems are mathematically valid; other solvers support them.

Impact

Found while writing/testing Java doc examples for #1999 — had to add an artificial non-binding linear constraint to two examples (quadratic-constraint-only, and a semi-continuous variable with no other constraints) purely to work around this.

Ask

Could someone with more context on the CSR/problem construction path confirm whether zero-row problems are meant to be supported, and if so where the fix belongs?