Fix/webp exif chunk bounds

[ssh4net]

Description

Fixes bounds handling for WebP EXIF metadata chunks.

Before this change, the WebP reader always skipped the first 6 bytes of an EXIF
chunk before calling decode_exif():

bytes + 6
size - 6

That assumed every WebP EXIF chunk was at least 6 bytes long and always started
with the optional Exif\0\0 prefix. A malformed WebP file with a shorter EXIF
chunk could therefore advance the pointer past the chunk payload and underflow
the remaining size passed to the EXIF parser.

This is reachable through normal OpenImageIO image-open paths, including tools
such as iinfo, iconvert, and oiiotool, when opening a malformed WebP file.

The fix changes the WebP reader to treat the EXIF chunk as a bounded byte span.
Before calling decode_exif(), it now verifies that the payload contains enough
bytes for a TIFF header, either at the start of the chunk or after an optional
Exif\0\0 prefix. The WebP reader no longer performs an unconditional 6-byte
skip; the shared EXIF decoder already handles the optional prefix safely.

Tests

Added WebP regression coverage for malformed short EXIF chunks.

The testsuite/webp test now generates WebP files with EXIF chunk payload
lengths:

• 0 bytes
• 4 bytes: Exif
• 5 bytes: Exif\0
• 6 bytes: Exif\0\0
• 13 bytes: Exif\0\0 plus a truncated TIFF header

Each generated file is opened through oiiotool to verify that malformed EXIF
metadata does not crash or read past the chunk buffer.

Validated locally with:

python3 -m py_compile testsuite/webp/src/make-short-exif-webp.py
git diff --check
cmake --build build-webp --target oiiotool -j 8

Also ran direct oiiotool smoke tests for all generated malformed WebP inputs.

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: Codex GPT5.5xHigh
  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.