fix(exr): handle multi-level hierarchical EXR channel names

[throb]

Summary

• Fix "Unable to choose decoder routines" error when loading EXR files with hierarchical dot-separated channel names (e.g. Blender/Cycles multi-layer renders)
• get_channel_names_by_layer() now splits on the last dot (rfind) instead of the first, so bg_wall.Combined.R produces layer bg_wall.Combined with channel R
• Add defensive bounds checks to prevent array out-of-bounds reads in FrameBuffer setup

Problem

EXR files with hierarchical channel names like bg_wall.Combined.R, bg_wall.CryptoObject00.r, fg_rocks.Diffuse Direct.B caused the OpenEXR library to throw "Unable to choose decoder routines".

The root cause was that get_channel_names_by_layer() split on the first dot, creating layers with 30+ channels (e.g. all bg_wall.* channels grouped under bg_wall). The reader's pix_type array is fixed at 4 elements, so the FrameBuffer setup loop read past the array bounds, producing undefined pixel types that OpenEXR's exr_decoding_choose_default_routines() rejected.

Fix

1. Layer grouping: Use rfind(".") instead of find(".") to split on the last dot. This produces proper sub-layers with 3-4 channels each (e.g. bg_wall.Combined → R,G,B,A)
2. FrameBuffer safety: Add if (ii >= 4) return; guard in the FrameBuffer setup lambda
3. Channel cap: Resize exr_channels_to_load to max 4 after assignment from the layer map

Test plan

• Tested with 56-channel Blender/Cycles render EXR containing hierarchical AOV names across 2 render layers (16 sub-layers total)
• Verified all 16 layers appear as separate streams in the AOV selector
• Verified playback works without decoder errors
• Verified simple RGBA EXRs (no dots in channel names) still work correctly

🤖 Generated with Claude Code