Unit: iterate SResourcePack by index instead of std::views::enumerate

[tomjn]

What

SplitResourcePackIntoPositiveNegative in Unit.cpp iterated a SResourcePack with std::views::enumerate:

for (auto [resourceID, value] : std::views::enumerate (pack)) { ... }

This is the only std::ranges/std::views use in the file. It's replaced with a plain index loop:

for (int resourceID = 0; resourceID < SResourcePack::MAX_RESOURCES; ++resourceID) {
    const auto value = pack.res[resourceID];
    ...
}

Why

std::views::enumerate (C++23, P2164) is not available across all standard libraries we target — notably libc++ on Apple Clang. The index loop is portable, behavior-identical, and matches how the rest of the codebase already iterates SResourcePack — rts/Sim/Misc/Resource.h uses for (int i = 0; i < MAX_RESOURCES; ++i) throughout. The enumerate call here was the odd one out.

MAX_RESOURCES is 2, so there is no readability cost.

Why this is cross-platform

No behavior change on any platform; master builds fine today, this just removes a libc++ portability blocker so no platform-specific fallback is needed downstream.

Provenance

Surfaced by the macOS port (#2991), which carried this same index loop as an __APPLE__-gated fallback (author: iamaperson000, credited via Co-authored-by). Applying it unconditionally means the macOS branch needs no gate here at all.

[sprunk]

I specifically used enumerate because ongoing resource work will decouple the underlying array from how many resources there actually are. Use d3dd051 instead.

[tomjn]

Closing — @sprunk confirmed std::views::enumerate is intentional (the ongoing resource work decouples the backing array from the resource count), and the index loop here hardcodes exactly the direct pack.res[i] access that's being moved away from. The accepted path is the Recoil::enumerate polyfill in Cpp23Compat.hpp (commit d3dd051), so this standalone change isn't the right approach. Thanks for the context.