Fix #7148: Andesite Tunnel not triggering on first segment of forward belts

[Apertyotis]

fix #7148

Issue

Andesite Tunnels placed on the first segment of a forward-moving belt never trigger, while the same setup works correctly on reverse belts.

This happens because belt logic only checks the upcoming segment index when items move forward.

For example:

• When an item moves from 0.9f to 1.1f, it transitions into segment index 1, triggering the tunnel at index 1.
• However, on a forward belt, the minimum starting position of an item is 0.0f.
• Since items never move from -1 → 0, the tunnel at index 0 is never evaluated.
• As a result, an Andesite Tunnel placed on the first segment of a forward belt can never activate.

In contrast, reverse belts do not suffer from this issue:

• On a 4-segment reverse belt, valid positions are [0, 4] with indices {0,1,2,3}.
• Inserted items begin at 4.0f and move toward 3.x.
• This naturally triggers the tunnel at index 3, which corresponds to the first physical segment of the belt.

Fix

To make forward belt behavior consistent with reverse belts:

When the belt moves forward and:

beltInventory.beltMovementPositive && current.beltPosition <= 0.0f

currentSegment is treated as -1.

The equality case (== 0.0f) is included because items are inserted at exactly 0.0f, which should logically represent the pre-first-segment boundary.

The < 0.0f case is necessary because blocked items may be pushed slightly negative (-0.01f), and due to integer truncation (int) -0.01f would otherwise still resolve to 0.

This is not the only possible fix.

For example, Brass Tunnels avoid this issue because they can be evaluated through a different timing mechanism. It would be possible to refactor Andesite Tunnel checks similarly.

However, that would involve deeper changes to belt logic.
The current fix is intentionally minimal and preserves previous behavior as much as possible.

Additional Observation (Not Addressed in This PR)

If maximum rpm is increased via config and belts exceed 480 RPM, items may move across multiple segments in a single tick. This can cause intermediate tunnels to be skipped entirely.

Funnels do not suffer from this issue because they iterate across all segments along the movement path. Applying similar path traversal logic to tunnels could prevent this edge case.

However, this would require a more substantial refactor, and I do not feel confident proposing a safe implementation for it.