Release 0.52.0

[tudddorrr]

No description provided.

[claude]

PR Review: Release 0.52.0

---

🟡 Code Quality

PlayerAlias now depends on PlayersAPI — entity→API coupling

Moving WriteOfflineAlias() into PlayerAlias requires the entity to reference PlayersAPI.offlineDataPath, which inverts the layering (entities should not depend on API classes). The previous design — a private method in PlayersAPI — was architecturally cleaner.

// PlayerAlias.cs — entity now reaches into API layer
Talo.Crypto.WriteFileContent(PlayersAPI.offlineDataPath, content);

The offlineDataPath was changed from private to public static solely to enable this. A cleaner fix would be to keep the write logic in PlayersAPI and pass it the alias, or keep offlineDataPath as an internal constant accessed through a dedicated utility, rather than exposing it via the API class.

---

🟡 Potential Bug

HandleIdentifierUpdated leaves Talo.CurrentPlayer.aliases stale

After ChangeIdentifier succeeds, Talo.CurrentAlias is replaced with the new alias and the offline cache + PlayerPrefs are updated — but Talo.CurrentPlayer.aliases still holds the old alias object. Any code accessing the player's alias list after this call will see the outdated identifier.

public void HandleIdentifierUpdated(PlayerAuthChangeIdentifierResponse res)
{
    Talo.CurrentAlias = res.alias;           // updates the reference
    Talo.CurrentAlias.WriteOfflineAlias();
    SetIdentifierPlayerPref();
    // Talo.CurrentPlayer.aliases is never updated
}

The fix is to also update the matching alias in Talo.CurrentPlayer.aliases (find by id, replace or mutate in place).

---

🔵 Minor

Inconsistent error handling between leading and trailing calls in DebouncedAPI

The leading call silently catches and logs exceptions:

ExecuteDebouncedOperation(operation).ContinueWith((t) => {
    op.isExecuting = false;
    if (t.IsFaulted) Debug.LogError(t.Exception);
}, TaskScheduler.FromCurrentSynchronizationContext());

The trailing call propagates the exception to the caller of ProcessPendingUpdates (i.e., TaloManager.Update()):

try { await ExecuteDebouncedOperation(key); }
finally { op.isExecuting = false; op.windowOpen = false; }

Both paths should use the same error handling strategy. If unhandled exceptions from trailing calls can surface into TaloManager.Update(), this could cause unexpected crashes at the Unity frame loop level.

---

Overall the debounce leading/trailing logic and the LeaderboardEntriesManager bump fix look correct.