perf: skip spectator iteration if container has holding player

[dudantas]

Description

Optimized onUpdateContainerItem and onRemoveContainerItem to avoid iterating over spectators when the container has a holding player. If a holding player is present, updates are sent directly to them, preventing unnecessary performance overhead. This change reduces unnecessary iterations and improves efficiency when handling item updates inside player containers.

Behaviour

Actual

Every container item update/removal iterates over all nearby spectators, even when the item belongs to a holding player.

Expected

When a holding player exists, only they receive the update, skipping the expensive spectator iteration.

Type of change

• Performance improvement (optimization without changing behavior)

How Has This Been Tested

Validated through gameplay testing and logging to ensure item updates are properly handled without iterating spectators when a holding player exists.

• Verified container updates work correctly when a holding player is present with visual studio profiling.
• Ensured spectator updates still occur when needed

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I checked the PR checks reports
• I have commented my code, particularly in hard-to-understand areas
• My changes generate no new warnings

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud