[BUG] cuOptGetErrorString should reject non-positive buffer sizes

[fallintoplace]

Describe the bug
While looking through the current main branch, I noticed that cuOptGetErrorString() checks solution and error_string_ptr, but it does not validate error_string_size before passing it to std::snprintf(...).

That means error_string_size == 0 still returns CUOPT_SUCCESS, and a negative cuopt_int_t size is forwarded straight into snprintf. In the same file, cuOptGetParameter() already rejects parameter_value_size <= 0, so this looks like a missed validation check rather than intentional API behavior.

Steps/Code to reproduce bug

1. Build cuOpt from source on current main.
2. Create or read any problem that produces a non-successful cuOptSolution.
3. Call cuOptGetErrorString(solution, buf, 0) or cuOptGetErrorString(solution, buf, -1).

Minimal example:

char buf[16];
cuopt_int_t st = cuOptGetErrorString(solution, buf, 0);

Current behavior: this goes through the API and returns CUOPT_SUCCESS.

Expected behavior: return CUOPT_INVALID_ARGUMENT for non-positive buffer sizes.

I first noticed this by source inspection in cpp/src/pdlp/cuopt_c.cpp: cuOptGetErrorString() passes error_string_size straight to std::snprintf(...), while cuOptGetParameter() in the same file already has an early <= 0 guard for its output buffer size.

Expected behavior
cuOptGetErrorString() should return CUOPT_INVALID_ARGUMENT when error_string_size <= 0, matching the validation pattern already used by cuOptGetParameter() and the rest of the C API.

Environment details (please complete the following information):

• Environment location: Bare-metal (local source checkout)
• Method of cuOpt install: from source

Additional context
This one seems small but worth fixing because it is public C API surface, and the neighboring getter already follows the safer pattern.

I also checked the file history while looking at this: the missing size check was present when cuOptGetErrorString() was added, and it stayed that way through the later memory-model refactor, so this does not look like a branch-specific regression.

A minimal fix would just be an early:

if (error_string_size <= 0) { return CUOPT_INVALID_ARGUMENT; }

right before the std::snprintf(...) call, plus a focused C API regression test.