fix(thumb): don't write thumbnail_* metadata to formats that can't hold a thumbnail

[jinhgkim]

Description

Noticed a thumbnail metadata leak in iconvert when converting from a format that supports thumbnails to one that doesn't. The thumbnail_* attributes ride along in the spec and get serialized, so the file claims a thumbnail it doesn't have.

oiiotool already stripped these, so I moved the stripping into ImageOutput::check_open() where it covers every writer and caller.

Also stopped ImageBuf treating those attributes as proof a thumbnail exists. Both read paths now take m_has_thumbnail from get_thumbnail()'s return. The ImageCache-backed path was ignoring the return entirely, so it and the direct path disagreed on the same file.

Optional Read

One thought I had while working on this: currently we check whether a thumbnail exists by looking at its width and height in ImageBuf, which I think is unreliable. rawinput even hacks around this guard, since twidth/theight aren't always populated by libraw when the file does contain a thumbnail - something I only learned recently! I feel we need a more reliable guard: something like the nsubimages mechanism, but an nthumbnails() we could check instead. That would break ABI though, so we could save it for 3.3. Just wanted to mention it so I don't forget.

Tests

Added test_thumbnail_attribs() that writes a spec claiming a thumbnail for every format that can't embed one and asserts it's absent on read back.

Assisted-by: Claude Code / Opus 5

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.

[lgritz]

Most file formats do not support arbitrary named metadata, and for those, these orphaned metadata items without real thumbnails will be harmless.

I think you catch the cases of using an ImageBuf, and oiiotool, but I wonder if we should also try to catch cases where by using the APIs directly.

If somehow those attributes leak into the ImageSpec written to an output file that doesn't support thumbnails but DOES support arbitrary metadata, should we try to catch it? Are there any formats we support that have that combination (no thumb, yes named metadata), and somewhere in the ImageOutput subclass for those formats themselves, also squash the orphaned metadata?

I agree with you that eventually, we'd like all the thumbnail metadata to disappear and be replaced by a real API that can handle multiple thumbnails (among other improvements).