fix: check mlx_detail_compile and mlx_closure_apply return values in CompiledFunction

[vernonstinebaker]

Proposed changes

Fixes #397.

CompiledFunction.innerCall() (Source/MLX/Transforms+Compile.swift) silently ignored the int return values of mlx_detail_compile and mlx_closure_apply. Both return 1 on failure and call mlx_error(). When called inside a withError scope the Swift error handler stores the error in an ErrorBox and execution continues — leaving resultVector empty. The single/two/three-array compile overloads then subscript into an empty array (result[0]), triggering a Swift trap that kills the process before withError can throw.

Fix:

• Capture the return value of mlx_detail_compile; return [] from innerCall if it fails.
• Capture the return value of mlx_closure_apply; return [] from innerCall if it fails.
• Guard against the empty-result crash in the three convenience overloads by replacing compileState.call(...)[0] with a safe let r = ...; return r.isEmpty ? MLXArray(0) : r[0].

The placeholder MLXArray(0) returned by the overloads on the error path is never observed by the caller — withError throws MLXError before the value is used.

MLXCustomFunction.swift:112 already uses the same pattern (precondition(status == 0, ...)) for its own mlx_closure_apply call; this PR makes Transforms+Compile.swift consistent.

Checklist

• I have read the CONTRIBUTING document
• I have run pre-commit run --all-files to format my code / installed pre-commit prior to committing changes
• I have added tests that prove my fix is effective or that my feature works
• I have updated the necessary documentation (if needed)

[davidkoski]

Changes look good.

I was thinking that perhaps compile should throw, but that is going to be trouble for statically defined functions and also be breaking API. I think this is a reasonable middle ground.