Fix for possible normalization issue for line corner points

[p-skakun]

Description

If points in PolylineVolume or Corridor are collinear, computation fails with error "Normalized result is not a number" in the line below, because sum of normalized forward and backward vectors is zero.

cesium/packages/engine/Source/Core/PolylineVolumeGeometryLibrary.js

Line 438 in 0e9a425

cornerDirection = Cartesian3.normalize(cornerDirection, cornerDirection);

The cornerDirection variable is only used within the doCorner === true execution branch, so I moved it inside the branch for better scoping. From my understanding, the forward and backward projection checks within the doCorner condition exclude the computation of corners for collinear points. As a result, normalizing cornerDirection in this execution branch should not cause any errors.

Issue number and link

Fixes #12254

Testing plan

This issue is difficult to replicate. I encountered it by chance, with the data shown in Sandcastle example attached to related issue.
I haven't yet found a way to generate synthetic data to reproduce the issue, mainly due to the scaleToSurface call, which modifies coordinates based on a specific location.

cesium/packages/engine/Source/Core/PolylineVolumeGeometryLibrary.js

Line 35 in 0e9a425

function scaleToSurface(positions, ellipsoid) {

To test it, I followed this approach:

• I created a simplified version of computePositions that omits the scaleToSurface call and other irrelevant operations. This resulted in a "Normalized result is not a number" error when passing a simple collinear line like [[0,0,0], [1,1,1], [2,2,2], [3,3,3]] as the positions input.
• I also tested the problematic data locally, both before and after the changes. The error was resolved after applying the changes.

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @p-skakun!

✅ We can confirm we have a CLA on file for you.

[ggetz]

Thank you for the fix @p-skakun! The approach here all makes sense to me.

Could we please add a unit test for this case for both CorridorGeometryLibrary.computePositions and PolylineVolumeGeometryLibrary.computePositions? I know there are no existing tests, but adding even one to confirm this edge case would be a huge benefit.

If you are feeling generous, we would of course appreciate additional unit tests for those functions, but that is certainly not expected to get this PR merged. 😄

[p-skakun]

I added a few tests, but the release-tests check is failing for an unrelated (at least, it appears that way) spec.

[ggetz]

Thanks @p-skakun! The CI test failure is due to #11958, not this PR.