rust/sedona-pointcloud: Improve integration test coverage for las and laz readers

[paleolimbot]

A couple of suggestions before merging:

Tests

• The previous projection test covered both .las and .laz; the rewrite only covers .las. Since LAZ goes through a separate decode path, it'd be good to keep the .laz assertion (or parameterize over both).
• Assertions check column count + type of column 0, but not the actual data. The interesting failure mode in bug(rust/sedona-pointcloud): projection pushdown does not slice batches; non-prefix projections fail or return wrong data #824 was returning the right schema with the wrong column — same UInt8 shape, wrong values. An assert_eq! on a value (e.g. classification = 0 for the single point in extra.las) would lock that down.

Scope

• LasSource::new(extension, table_schema: impl Into<TableSchema>) is an unrelated public-API change. Worth pulling out into a separate PR (or dropping) so this one is purely a fix.
• The field reordering in LasSource and LasOpener is noisy in the diff without changing behaviour; reverting it would make the fix easier to cherry-pick.

Originally posted by @jiayuasu in #825 (comment)

[b4l]

As we do projection after decoding, covering both .las and .laz is certainly valuable for when it eventually will be pushed further down. The key issue and interesting failure is covered by the test now. However the silent truncating of record batches to the number of columns in the schema is something that probably needs to be investigated and resolved upstream in DataFusion. Also the scope is now out of scope, though I will try to adhere to it better in the future.

[paleolimbot]

I think the projection system went through a bit of an overhaul in DataFusions 52, 53, and possibly a few in the pending 54 to support projections that include nested references (e.g., a struct column in Parquet) and pruning row groups/pages from predicates on those columns...they may have improved the errors regarding mismatched schemas (but also maybe not 🙂 )

Given that there's some overhead to picking up a SedonaDB issue and fixing I'm almost always happy to review minor improvements alongside fixes 🙂 (I certainly do it!)