resample: target_resolution and scale_factor input validation is leaky

[brendancol]

Describe the bug

xrspatial.resample.resample validates method and the sign of the resolved scale factors but does not validate the shape or finiteness of target_resolution / scale_factor up front. Four bad inputs slip past the guard at the top of the function and fail later with confusing errors (or, worse, silently use the wrong axis).

Around resample.py:1243 and resample.py:1249 the function indexes target_resolution[0], target_resolution[1], scale_factor[0], scale_factor[1] without checking the sequence length, and divides abs(res_y) / target_resolution[...] without checking the value.

Four cases

1. Overlong tuple -- target_resolution=(10, 20, 30) or scale_factor=(2, 2, 2) is accepted silently. The extra element is dropped.
2. Short tuple -- target_resolution=(10,) or scale_factor=(2,) raises IndexError: tuple index out of range from deep inside the function, with no hint about which parameter is wrong.
3. Zero -- target_resolution=0 or target_resolution=(0, 5) raises ZeroDivisionError from the abs(res_y) / target_resolution line. scale_factor=0 is already caught later by the scale_y <= 0 check, but only after the geometry math runs.
4. NaN / inf -- scale_factor=float('nan') or target_resolution=float('nan') propagates through the math and fails much later with a numpy ValueError: cannot convert float NaN to integer when _output_shape tries to round.

Expected behavior

Each of the four cases should raise a ValueError at the top of resample(), before any geometry work, naming the parameter and the offending value. Roughly:

• target_resolution=(10, 20, 30) -> ValueError: target_resolution must have length 2, got length 3
• scale_factor=(2,) -> ValueError: scale_factor must have length 2, got length 1
• target_resolution=0 -> ValueError: target_resolution must be > 0, got 0
• scale_factor=float('nan') -> ValueError: scale_factor must be finite and > 0, got nan

Scope

Validation belongs at the public boundary (resample()), not sprinkled through the per-backend helpers. The existing scale_y <= 0 or scale_x <= 0 check stays as a defence-in-depth catch but should no longer be the first line of feedback the user sees.

Additional context

Surfaced by a code review pass over the resample module. Sibling issues in the input-validation label (#2566, #2568, #2558) follow the same pattern: validate inputs at the entry point, fail with a message that names the parameter.