Fix spectator switching during replay when using D-Pad or analog stick

[windows10isnotavailable]

Summary

Previously, during replay mode, pressing the D-Pad or moving the analog stick would unintentionally switch the currently spectated player.
This behavior was inconsistent with the intended control scheme.

Fix

Now, the spectator player can only be switched explicitly via the following bindings:

• controls.ui.next
• controls.ui.previous

All other key or gamepad inputs no longer affect spectator switching.

[ipodtouch0218]

The left/right buttons are supposed to change who you're spectating. Those inputs have no other use, after the "Freecam" became its own button rather than an entry in the list.

[windows10isnotavailable]

I ran it through translation but couldn’t fully grasp the intent, so here is a more precise explanation to avoid miscommunication.

Based on my current understanding of the input bindings, here is why I made this change:

In version v2.0.3, the spectator could only be switched via the following bindings:

• ui.options.controls.ui.next
• ui.options.controls.ui.previous

Meanwhile, the D-Pad and analog stick inputs (ui.options.controls.ui.navigate), which are normally used for navigating the UI, did not affect spectator switching.

Starting with v2.0.4, spectator switching became possible through three bindings:

• ui.options.controls.ui.navigate
• ui.options.controls.ui.next
• ui.options.controls.ui.previous

My interpretation is that this change was intentional for in-game spectator mode, where D-Pad/analog stick input makes sense for switching between players.
However, in replay mode, this creates a problem:
when navigating the replay control UI (e.g., moving the cursor to the play button), using the D-Pad or analog stick also switches the spectated player unintentionally.

That is why this pull request disables ui.options.controls.ui.navigate only during replay mode, so that UI navigation and spectator switching don’t interfere with each other.
This does not affect in-game spectator mode, where the behavior should remain as intended.

Additionally, the following bindings are not touched by this change and continue to work as before:

• ui.options.controls.ui.next
• ui.options.controls.ui.previous