api: add OIIO_NODISCARD_ERROR to ImageOutput methods

[rose413]

Description

• Annotate all ImageOutput write methods (write_image, write_scanline, write_scanlines, write_tile, write_tiles, write_rectangle, write_deep_scanlines, write_deep_tiles, write_deep_image), as well as open, close, and copy_image, with OIIO_NODISCARD_ERROR.
• Also fix the handful of internal callsites (imagebuf.cpp, maketexture.cpp, py_imagebuf.cpp, iconvert.cpp, imagebufalgo_test.cpp, and imagespeed_test.cpp) that were previously ignoring the return value of close(), either by propagating the error or by casting to void where the error path is already being handled.
• Assisted-by: Claude Sonnet 4.6
• Reference: [FEATURE REQUEST] Add [[nodiscard]] to image read/write methods #4781

Tests

• tested against unit_imageinout, unit_imagebuf, unit_imagebufalgo

Checklist:

• I have read the guidelines on contributions and code review procedures.
• I have read the Policy on AI Coding Assistants
  and if I used AI coding assistants, I have an Assisted-by: TOOL / MODEL
  line in the pull request description above.
• I have updated the documentation if my PR adds features or changes
  behavior.
• I am sure that this PR's changes are tested in the testsuite.
• I have run and passed the testsuite in CI before submitting the
  PR, by pushing the changes to my fork and seeing that the automated CI
  passed there. (Exceptions: If most tests pass and you can't figure out why
  the remaining ones fail, it's ok to submit the PR and ask for help. Or if
  any failures seem entirely unrelated to your change; sometimes things break
  on the GitHub runners.)
• My code follows the prevailing code style of this project and I
  fixed any problems reported by the clang-format CI test.
• If I added or modified a public C++ API call, I have also amended the
  corresponding Python bindings. If altering ImageBufAlgo functions, I also
  exposed the new functionality as oiiotool options.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: rose413 / name: rose413 (3ead3a8)

[lgritz]

The failure for the "VFX2023" test is unrelated to your PR and is being fixed separately. If everything else is ok, we will not hold up the merge just because of that.

[lgritz]

This is looking really good.

I made some suggestions -- I think a few of the places in tests where you ignore the results, probably it would be better if we checked, and exit the loops early if there is a problem.

Oh, I guess in my explanations, I showed how to detect and exit the loop, but then didn't handle it. For tests, you don't need nice error recovery, but maybe just do a OIIO_CONTRACT_ASSERT(ok) after the loop?

[lgritz]

Maybe?

Suggested change

	(void)out->write_image(bufspec.format, &buffer[0]);
	ok = out->write_image(bufspec.format, &buffer[0]);
	OIIO_ASSERT(ok);

[lgritz]

I wrote OIIO_ASSERT, but probably OIIO_CONTRACT_ASSERT(ok) is the "more modern" idiom we're aiming for most of the time.

[lgritz]

Maybe

    bool ok = true;
    for (int y = 0; y < outspec.height && ok; ++y) {
        ok = out->write_scanline(y + outspec.y, outspec.z, bufspec.format,
                                 &buffer[scanlinesize * y]);
    }

[lgritz]

here, too

[lgritz]

Same here, maybe more like

bool ok = true;
for (int z = 0; z < outspec.depth && ok; ...) {
    for (int y = 0; y < outspec.height && ok; ...) {
        for (int x = 0; y < outspec.width && ok; ...) {
            ok = out->write_tile(...)

I guess I'm superstitious about ignoring the return code, that's what we're trying to be caching. Even though this is a test... what better time to catch a problem then when we're testing?

[lgritz]

I have a feeling that you did a reformat of code you weren't really trying to change, and you must have a different version of clang-format locally than we are using in CI.