[BUG] cuOptGetProblemStringArrayAttribute rejects a problem with no names instead of reporting it

Describe the bug

cuOptGetProblemStringArrayAttribute compares the stored name vector against the caller's count and fails if they differ:

const auto& names = (attribute == CUOPT_STRING_ARRAY_VARIABLE_NAMES) ? iface->get_variable_names()
                                                                     : iface->get_row_names();
if (names.size() != count) { return CUOPT_INVALID_ARGUMENT; }

A problem built without names — which is legal, and is what cuOptCreateProblem produces — stores an empty vector. A caller that sizes its buffer from cuOptGetNumVariables, as the documentation implies, therefore passes count = numVariables against names.size() == 0 and gets CUOPT_INVALID_ARGUMENT.

The caller cannot distinguish that from a genuine size mismatch, and there is no attribute reporting how many names are stored, so it cannot pre-check either.

Steps/Code to reproduce bug

1. cuOptCreateProblem(...) with 2 variables and no names.
2. cuOptGetProblemStringArrayAttribute(problem, CUOPT_STRING_ARRAY_VARIABLE_NAMES, 2, out).
3. Returns CUOPT_INVALID_ARGUMENT rather than indicating that the problem has no names.

Expected behavior

"This problem has no names" should be reportable rather than indistinguishable from a caller error. Either return the generated default names so the count always matches numVariables, or add a count attribute the caller can query first, or define a distinct status for the empty case.

Additional context

Found while reviewing the Java bindings (#1524), where this is one of the reasons cuopt_jni.cpp still reads names through the internal header instead of the C API. Raised by @chris-maes in review: https://github.com/NVIDIA/cuopt/pull/1524#discussion_r3854928177

Related: #1703 covers the broader set of problem-model accessors the C API is missing.