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.