OpenEXR 3.3.2 crashes when reading tiled files

Has been noticed with [GDAL](https://gdal.org) when alpine:edge has upgraded from OpenEXR 3.1.13 to 3.3.2 (https://github.com/OSGeo/gdal/pull/11352)

Can be reproduced with the following sample file [temp.exr.zip](https://github.com/user-attachments/files/17901330/temp.exr.zip)
and the following procedure:

```
docker run --rm -it -v $PWD:$PWD alpine:edge
# under Docker
apk add cmake make g++ proj-dev openexr-dev curl
curl https://download.osgeo.org/gdal/3.10.0/gdal-3.10.0.tar.gz --output gdal-3.10.0.tar.gz
tar xvzf gdal-3.10.0.tar.gz
cd gdal-3.10.0
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Debug -DGDAL_BUILD_OPTIONAL_DRIVERS=OFF -DOGR_BUILD_OPTIONAL_DRIVERS=OFF -DGDAL_ENABLE_DRIVER_EXR=ON -DACCEPT_MISSING_LINUX_FS_HEADER=ON
make -j$(nproc)
export LD_LIBRARY_PATH=$PWD
export PATH=$PWD/apps:$PATH
apk add valgrind
valgrind gdallocationinfo /path/to/temp.exr 0 0
```

outputs:
```
==4165== Memcheck, a memory error detector
==4165== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==4165== Using Valgrind-3.24.0 and LibVEX; rerun with -h for copyright info
==4165== Command: gdallocationinfo /home/even/gdal/gdal/build_ci_alpine/temp.exr 0 0
==4165==
Report:
Location: (0P,0L)
Band 1:
==4165== Invalid write of size 8
==4165== at 0x6B2F833: ??? (in /usr/lib/libOpenEXRCore-3_3.so.32.3.3.2)
==4165== by 0x6B2FFEC: ??? (in /usr/lib/libOpenEXRCore-3_3.so.32.3.3.2)
==4165== by 0x6B3828A: exr_decoding_run (in /usr/lib/libOpenEXRCore-3_3.so.32.3.3.2)
==4165== by 0x655B75E: ??? (in /usr/lib/libOpenEXR-3_3.so.32.3.3.2)
==4165== by 0x6558BFF: Imf_3_3::TiledInputFile::readTiles(int, int, int, int, int, int) (in /usr/lib/libOpenEXR-3_3.so.32.3.3.2)
==4165== by 0x655B505: Imf_3_3::TiledInputFile::readTile(int, int, int, int) (in /usr/lib/libOpenEXR-3_3.so.32.3.3.2)
==4165== by 0x53F7F66: GDALEXRRasterBand::IReadBlock(int, int, void*) (exrdataset.cpp:162)
==4165== by 0x551A1F7: GDALRasterBand::GetLockedBlockRef(int, int, int) (gdalrasterband.cpp:2006)
==4165== by 0x55FF07D: GDALRasterBand::IRasterIO(GDALRWFlag, int, int, int, int, void*, int, int, GDALDataType, long long, long long, GDALRasterIOExtraArg*) (rasterio.cpp:458)
==4165== by 0x5518A5A: GDALRasterBand::RasterIO(GDALRWFlag, int, int, int, int, void*, int, int, GDALDataType, long long, long long, GDALRasterIOExtraArg*) (gdalrasterband.cpp:435)
[ ... snip ... ]
==4165== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==4165==
==4165==
==4165== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==4165== Access not within mapped region at address 0x0
==4165== at 0x6B2F833: ??? (in /usr/lib/libOpenEXRCore-3_3.so.32.3.3.2)
==4165== by 0x6B2FFEC: ??? (in /usr/lib/libOpenEXRCore-3_3.so.32.3.3.2)
==4165== by 0x6B3828A: exr_decoding_run (in /usr/lib/libOpenEXRCore-3_3.so.32.3.3.2)
==4165== by 0x655B75E: ??? (in /usr/lib/libOpenEXR-3_3.so.32.3.3.2)
==4165== by 0x6558BFF: Imf_3_3::TiledInputFile::readTiles(int, int, int, int, int, int) (in /usr/lib/libOpenEXR-3_3.so.32.3.3.2)
==4165== by 0x655B505: Imf_3_3::TiledInputFile::readTile(int, int, int, int) (in /usr/lib/libOpenEXR-3_3.so.32.3.3.2)
==4165== by 0x53F7F66: GDALEXRRasterBand::IReadBlock(int, int, void*) (exrdataset.cpp:162)
[ ... snip ... ]
==4165== If you believe this happened as a result of a stack
==4165== overflow in your program's main thread (unlikely but
==4165== possible), you can try to increase the size of the
==4165== main thread stack using the --main-stacksize= flag.
==4165== The main thread stack size used in this run was 8388608.
```

Start with the Alpine Docker reproduction and sample temp.exr.zip, then inspect exrdataset.cpp at GDALEXRRasterBand::IReadBlock, identified in the Valgrind trace. Compare the tiled-file read path under OpenEXR 3.3.2 and verify the result with gdallocationinfo and Valgrind. Done means the sample no longer produces the invalid write or SIGSEGV.

Written by the indexing model from the issue text.