Handle corrupted LAZ input explicitly instead of continuing with bad data

[bloom256]

Description

Sometimes an input LAZ file is corrupted - for example because of firmware or copy errors. In such cases LASzip may report errors like:

[error] DLL ERROR: reading point 1150000

Right now odometry may still continue using the corrupted file. This is dangerous:

• some bad points may have huge coordinates and break algorithms
• some points may be skipped, which creates gaps in data
• trajectory quality becomes bad in those places, but the real cause is not reported clearly

Expected behavior

Corrupted input should be handled explicitly, not silently propagated into odometry.

Possible approach

• validate point ranges in LiDAR coordinate system during input
• treat LASzip read errors as fatal, or at least emit a strong warning
• optionally stop odometry on read errors
• optionally split the session around the corrupted region instead of continuing blindly

Why

• prevents bad trajectories caused by corrupted input
• makes the root cause clear