Raise a clear error for non-2D custom kernels

[brendancol]

Closes #2842

custom_kernel in xrspatial/convolution.py unpacked rows, cols = kernel.shape without first checking the kernel was 2D. A 1D or 3D kernel passed to apply, focal_stats, or hotspots (all of which route through custom_kernel) leaked a raw ValueError: not enough values to unpack (expected 2, got 1).

• Added an ndim != 2 check in custom_kernel that raises a clear ValueError reporting the offending shape, before the shape unpacking.
• Covered the three public entry points with 1D and 3D kernels, plus a direct custom_kernel unit test.

The check is backend-independent (it runs on the kernel argument before any dispatch), so it applies to numpy, cupy, dask+numpy, and dask+cupy alike.

Test plan:

• New tests in test_convolution.py and test_focal.py pass
• Existing convolution tests still pass

[brendancol]

PR Review: Raise a clear error for non-2D custom kernels

Blockers (must fix before merge)

None.

Suggestions (should fix, not blocking)

None.

Nits (optional improvements)

• convolution.py:333-335: the new ndim branch uses the same two-string-argument ValueError form as the existing odd-shape branch below it ("Received ...", "A custom kernel ..."). Worth knowing: passing two positional args to ValueError stores them as a 2-tuple in args, so the printed message is the tuple rather than one sentence. That is a pre-existing pattern in this function, not something this PR introduced, and matching it is the right call. Noting it only for the record.

What looks good

• The check sits before rows, cols = kernel.shape, so the cryptic unpacking error can no longer surface.
• The message reports the bad shape via kernel.shape, which reads correctly for both the 1D case (e.g. (3,)) and higher-dim cases (e.g. (3, 3, 3)).
• Tests cover all three public entry points (apply, focal_stats, hotspots) with both 1D and 3D kernels, plus a direct unit test on custom_kernel. Each entry-point/kernel combo passes independently.
• The validation is backend-independent: it runs on the kernel argument before any ArrayTypeFunctionMapping dispatch, so numpy, cupy, dask+numpy, and dask+cupy all behave the same. No per-backend tests needed.

Checklist

• Algorithm matches reference/paper: n/a (validation-only change)
• All implemented backends produce consistent results: yes, validation runs pre-dispatch
• NaN handling is correct: n/a
• Edge cases covered by tests: yes (1D and 3D kernels)
• Dask chunk boundaries handled correctly: n/a
• No premature materialization or unnecessary copies: yes, no array ops added
• Benchmark exists or is not needed: not needed
• README feature matrix updated: not needed (no new function)
• Docstrings present and accurate: yes; the custom_kernel docstring ("Validates a custom kernel") still holds