fix: bug with not tracking limit of spawned players in custom roles

[TiBarification]

Description

Describe the changes
Fixes bug with custom roles spawn system

What is the current behavior? (You can also link to an open issue here)
ignores limit for spawn

What is the new behavior? (if this is a feature change)
do not give custom role if limit was reached

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
no

Other information:

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentations

Submission checklist

• I have checked the project can be compiled
• I have tested my changes and it worked as expected

Patches (if there are any changes related to Harmony patches)

• I have checked no IL patching errors in the console

Other

• Still requires more testing

[Copilot]

Pull Request Overview

This PR addresses a bug in the custom role spawn system by enforcing the configured player limit.

• Added a check to skip role assignment once the spawn limit is reached.
• Treated a limit of 0 as “unlimited” to maintain prior behavior.

Comments suppressed due to low confidence (2)

EXILED/Exiled.CustomRoles/API/Features/CustomRole.cs:927

• There’s no test verifying that SpawnProperties.Limit is enforced correctly. Consider adding unit or integration tests to cover scenarios where the limit is reached and when it’s treated as unlimited (limit == 0).

            if (!IgnoreSpawnSystem && SpawnChance > 0 && !Check(ev.Player) && ev.Player.Role.Type == Role && Loader.Random.NextDouble() * 100 <= SpawnChance && (SpawnProperties.Limit == 0 || TrackedPlayers.Count < SpawnProperties.Limit))

EXILED/Exiled.CustomRoles/API/Features/CustomRole.cs:927

• [nitpick] Using Limit == 0 to represent "unlimited" can be non-intuitive. You might consider using null or -1, or ensure the API docs clearly state that zero disables the limit check.

            if (!IgnoreSpawnSystem && SpawnChance > 0 && !Check(ev.Player) && ev.Player.Role.Type == Role && Loader.Random.NextDouble() * 100 <= SpawnChance && (SpawnProperties.Limit == 0 || TrackedPlayers.Count < SpawnProperties.Limit))

[Copilot]

[nitpick] This condition is becoming quite long and could be extracted into a well-named helper method (e.g. CanSpawnMorePlayers(ev.Player)) to improve readability and reduce complexity.

Suggested change

	if (!IgnoreSpawnSystem && SpawnChance > 0 && !Check(ev.Player) && ev.Player.Role.Type == Role && Loader.Random.NextDouble() * 100 <= SpawnChance && (SpawnProperties.Limit == 0 || TrackedPlayers.Count < SpawnProperties.Limit))
	AddRole(ev.Player);
	}
	if (CanSpawnMorePlayers(ev.Player))
	AddRole(ev.Player);
	}
	private bool CanSpawnMorePlayers(Player player)
	{
	return !IgnoreSpawnSystem &&
	SpawnChance > 0 &&
	!Check(player) &&
	player.Role.Type == Role &&
	Loader.Random.NextDouble() * 100 <= SpawnChance &&
	(SpawnProperties.Limit == 0 || TrackedPlayers.Count < SpawnProperties.Limit);
	}