Bug fix: guard asin/acos inputs outside [-1, 1] in osl

[bhouston]

I noticed via the https://material-fidelity.ben3d.ca test suite that out of range asin/acos values render different in MaterialX OSL as compared to the GLSL / Metal versions.

Before fix render comparisons:

This updates the genosl stdlib implementations for asin and acos to explicitly guard out-of-domain inputs so that the resulting value matches that produced by materialx glsl.

• ND_asin_float: asin(in) -> mx_ternary(abs(in) <= 1.0, asin(in), 0.0)
• ND_acos_float: acos(in) -> mx_ternary(abs(in) <= 1.0, acos(in), 0.0)

Why

In degenerate-but-valid authoring cases, some graphs intentionally feed values outside [-1, 1] into inverse trig nodes. Backend behavior for out-of-domain inputs can differ (NaN propagation, clamping, or undefined results), which causes renderer divergence.

This change makes genosl behavior explicit and deterministic for those edge cases, improving cross-backend consistency.

Validation

After fix render (I also fixed the blender-materialx-importer as well) comparisons:

Notes

This PR is intentionally minimal and only changes genosl source expressions for float asin/acos.

[jstone-lucasfilm]

@bhouston This is an important issue to address in the cross-language parity for MaterialX, but I don't think the solution is quite as simple as adding new guards in OSL.

See #2914 (comment) for thoughts on how we might proceed with this category of improvement.