Ensure leaderboard cache is always correctly sorted

[tudddorrr]

No description provided.

[claude]

Code Review: Leaderboard Cache Sorting

---

🐛 Potential Bugs or Issues

Binary search edge case: The FindInsertPosition method in LeaderboardEntriesManager.cs doesn't validate that all entries have the same LeaderboardSortMode. If entries with mixed sort modes exist in the cache, the binary search could produce incorrect results since it assumes uniform sorting direction.

DateTime parsing without validation: In CompareEntries at line 82, DateTime.Parse(a.createdAt) could throw an exception if createdAt is null or malformed. Consider using DateTime.TryParse with a fallback.

---

⚡ Performance Considerations

Redundant position updates: After insertion, all entries in the list have their positions updated (lines 34-36). For large leaderboards, consider updating only positions from the insertion point onwards rather than the entire list.

Property getter inefficiency: The LeaderboardSortMode property getter performs string operations on every access. Since sort mode is unlikely to change, consider caching the parsed enum value.

---

🔒 Security Concerns

No significant security issues identified.

---

🔄 Backwards Compatibility

New required fields: The addition of createdAt, leaderboardName, leaderboardInternalName, and leaderboardSortMode fields to LeaderboardEntry could break deserialization of existing cached data if not properly handled. Ensure these fields have sensible defaults or migration logic.

Changed demo scene configuration: The LeaderboardsDemo scene now uses "the one with spaces" instead of "team-scores". Verify this change is intentional and documented for existing users of the demo.