perf: index standings import opponents by name instead of linear search

[Rathoz]

Summary

• Per-match-opponent linear Opponent.same scan replaced by an Opponent.toName-keyed map, reducing complexity from O(matches × opponents) to O(matches).
• Team opponents get a one-time Opponent.same fallback scan to handle renamed teams (which differ by name but compare equal via historicaltemplate); on a hit the new key is aliased into the map so the cost is paid at most once per renamed team.
• TBD opponents continue to collapse onto a single entry (same behavior as before — they resolve to the same Opponent.toName key and are filtered out by Opponent.isTbd at the end).

How did you test this change?

• busted --run=ci: 605 successes / 0 failures / 0 errors — includes spec/standings_import_spec.lua (7 cases covering dedupe across rounds, TBD dropping, score mappers).
• luacheck lua/wikis/commons/Standings/Parse/Lpdb.lua: 0 warnings / 0 errors.
• Based on standings-tests-ai (PR test: add integration tests for standings #7647), whose import spec covers the relevant behavior.

🤖 Generated with Claude Code

[mbergen]

"renamed teams have differing names" is an incorrect assumption if i am not mistaken:

• Opponent.toName returns TeamTemplate.toPageName (with normalized underscores)
• TeamTemplate.toPageName returns set pagename, resolves redirects, and normalizes underscores

A correctly setup HTT should have page redirects for each of the subtemplates to the same page.
Thus they'd end up with the same name via Opponent.toName.

This would only be different if we remove the forced resolving of redirects (which i'd personally advocate for due to A/B teams, but not sure if that is going to happen and the side effects of it)

[hjpalpha]

that is not necessarily true
there exist some team templates that have different page names set in their sub templates where no redirect exists between them
so if you would catch such a tt and process it at different dates (one before, one after the switch) you would get different pagenames returned

[mbergen]

What is the usecase of such a TT?

[hjpalpha]

no idea i hate them
iirc cs had some of them for some reasons

[mbergen]

Ah, you refer to the mibr vs MIBR things.
IIRC they fixed these by now, as they had other things broken.

[hjpalpha]

yeah exactly
if those are solved, then you are right :)

[Copilot]

Pull request overview

This PR optimizes standings import from LPDB match records by replacing per-opponent linear scans with an Opponent.toName-keyed lookup table, aiming to reduce import time from O(matches × opponents) to O(matches) while preserving existing dedupe behavior (including renamed teams via historicaltemplate fallback).

Changes:

• Added an opponentsByName map to index StandingTableOpponentData by Opponent.toName.
• Updated parseMatch to use O(1) lookups, with a one-time Opponent.same fallback scan for team renames.
• Updated the parseMatch call site to pass the new map through the import flow.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ElectricalBoy]

wouldn't using return vals from Opponent.toName essentially reintroduce #6727?
iirc it was the reason we moved away from using Opponent.toName