Bug fix: genmsl image node handling for MaterialX constant texture address

[bhouston]

Metal previously relied on MTLSamplerAddressModeClampToBorderColor for constant addressing. Metal samplers only support opaque black/white border colors, so arbitrary MaterialX image default values, for example bright green-yellow, rendered incorrectly as white.

Fix

• Added MSL-specific image implementations for all image output types: float, color3, color4, vector2, vector3, and vector4.
• Added a shared helper, mx_image_coord_out_of_bounds, that checks transformed UVs against [0, 1] only for axes using constant address mode.
• When out of bounds, the image node now returns its MaterialX default input; otherwise it samples the texture normally.
• Updated stdlib_genmsl_impl.mtlx to use these MSL image implementations instead of reusing the GLSL versions.

How It Was Realized

This was found through fidelity samples that set uaddressmode and vaddressmode to constant with a non-white default color. GLSL, OSL, Three.js, and Blender produced the expected default color outside the valid UV range, while Metal showed white. Inspecting MetalTextureHandler.mm showed the Metal backend maps constant to sampler border color and chooses only black or white based on defaultColor[0], which cannot represent arbitrary defaults (such as purple in this example.(

Validation

Rendered the focused address-mode samples through materialx-metal:

pnpm cli render --materials "re:image_addressmode_(constant|clamp|periodic|mirror)$" --renderers materialx-metal

All 4 renders succeeded, and the constant-mode sample now shows the expected magenta default region.