fix: prevent red alloy/insulated wire from becoming unpowerable after a thrown lookup

[arsdragonfly]

Summary

RedstonePropagator's global redstone flags are toggled around connection discovery and signal calculation without try/finally, so a neighbor lookup that throws mid-way leaves the static flag stuck in its temporary value for the rest of the session.

Most visibly, FramedRedwirePart and RedstoneTubePart#discoverStraightOverride set canConnectRedwires = false and restore it afterwards. If RedstoneInteractions.{otherConnectionMask,connectionMask} throws (e.g. a modded neighbor, or a partially-loaded/unloaded chunk during the lookup), the restore line is skipped and the flag is left false.

RedwirePart#canConnectRedstone is the only consumer of canConnectRedwires(). Once it is stuck false, every face red alloy / insulated wire reports no redstone connection and reads zero vanilla power through RedstoneInteractions.getPowerTo — so newly placed (and existing) wires can no longer be powered at all. Gates and vanilla redstone dust are unaffected (different flags / code paths), which is exactly why only the wires appear broken.

The flags are only reset on ServerAboutToStartEvent, so:

• on a dedicated server the corruption persists for the entire session (matches the reported "lever-next-to-red-alloy-wire stops working mid-session, even a straight line"), while
• in singleplayer it silently recovers on each world reload, which is why it's hard to reproduce there.

Fix

Wrap every RedstonePropagator flag toggle in try/finally so the flags are always restored, even if a lookup throws:

• canConnectRedwires in discoverStraightOverride (RedwirePart, FramedRedwirePart, RedstoneTubePart)
• the dustProvidesPower / redwiresProvidePower flags in calculateSignal (RedwirePart, FramedRedwirePart, RedstoneTubePart, ArrayGatePart)

No behavioral change on the happy path — only exception safety. The flag handling is identical across 1.20.1, 1.20.4, and 1.21.1, so the same fix is being submitted to each active branch.

[MrTJP]

Thanks! Will take a look tonight

[MrTJP]

None of these try/catch blocks in this PR should be swallowing the exception. At least log it out via the module's respective logger (i.e. ProjectRedExpansion.LOGGER, etc)

[covers1624]

try-finally does not swallow exceptions, it will always propagate exceptions

[MrTJP]

True, I guess whatever is catching it further up should log it out anyway. This is good for now, i might rework it into a lambda based call that does the wrap, bc doing this everywhere is error-prone

[MrTJP]

Thanks for the PR. Had a minor comment. Please log the exceptions out if they occur rather than hiding them. The visibility can help actually fix the underlying issues when appropriate.