main is red: strict xfail in test_reproject_streaming_3101 XPASSes after #3111 fixed the #3100 crash

[brendancol]

The pytest workflow fails on main at 8c3d07e:

FAILED xrspatial/tests/test_reproject_streaming_3101.py::TestStreaming3D::test_3d_source_streams - [XPASS(strict)] 2-D output buffer vs 3-D tiles, see #3100

Two PRs landed two minutes apart and each was green against the main it branched from:

• 1a63f90 (Match streaming reproject output dtype to the other backends (#3093) #3111) fixed the streaming reproject 2-D output buffer, including the crash on 3-D (y, x, band) sources. Its commit message says so: "It also allocated 2-D, which crashed on 3-D sources... carry the band axis through."
• 8c3d07e (Add tests for the streaming reproject fallback path (#3101) #3118) added TestStreaming3D::test_3d_source_streams with @pytest.mark.xfail(strict=True, raises=ValueError, reason="2-D output buffer vs 3-D tiles, see #3100").

With both on main, the test passes and the strict xfail turns that into a failure. Not a flake: the same XPASS shows up on main's own run (27278776057) and on PR branches that merged 8c3d07e (e.g. #3175, run 27278859092). Every open PR that syncs with main will go red until this is fixed.

Fix is the happy-path kind: the #3100 behavior is fixed, so drop the xfail marker (and the stale "Once #3100 is fixed the xfail comes off" comment at test_reproject_streaming_3101.py:181) and let the assertions run for real. Worth closing #3100 too if nothing else is left there.

[brendancol]

Fixed by #3181 (same change as the now-closed #3179): the strict xfail is off and main's pytest run is green again.