nextAvailableVNet fails when using multiple blocks and smallest_cidr option true if no IP range is available in first block

**Describe the bug**
nextAvailableVNet fails with an internal server error (500) when using multiple blocks and smallest_cidr option true if no IP range is available in first block

**To Reproduce**
Steps to reproduce the behavior:
1. Create API request (e.g. with Powershell) against the /api/tools/nextAvailableVNet endpoint with multiple blocks and define a size for which you know, that no such IP range exists anymore in the first block (e.g. Block-001) but ranges are available in the second block (Block-002). Set reverse_search to $false and smalles_cidr to $true.

```
$body = @{
space = 'Azure'
blocks = @("Block-001", "Block-002", "Block-003")
size = 19
reverse_search = $false
smallest_cidr = $true
} | ConvertTo-Json -Depth 10

Invoke-RestMethod -Method Post `
-Uri 'https://ipam.azure.six-group.com/api/tools/nextAvailableVNet' `
-Headers @{
'accept' = 'application/json'
'Authorization' = "Bearer $token"
} `
-ContentType 'application/json' `
-Body $body
```

**Expected behavior**
IPAM returns information about the free IP range from Block-002.

**Screenshots**
Screenshots are attached

**Desktop (please complete the following information):**
- OS: Windows 11
- Browser: Edge Version
- Version 151.0.4129.59 (Official build) (64-bit)
- PowerShell Version (Invoke_RestMethod): 7.5.4

**Additional context**
- Issue only appears when first block (Block-001) can't find a free IP range for the requested size
- When another block (e.g. Block-002) is used as first searching block in the API request, it would find a free IP range for the requested size
- IPAM API endpoint /api/tools/nextAvailableVNet theoretically supports an array as input as documented in [Azure IPAM - Swagger UI](https:////api/docs#/tools), however, tests have shown that it always returns a Internal Server Error 500 - also seen in the Log stream of the app (see printscreens).
- I was able to narrow down the issue further and have seen that the **issue only appears if "smallest_cidr" is set to true**. If smallest_cidr is set to false, the API returns a free IP range from the next block (SIX-Azure-010) successfully. It seems to be a code bug when using that feature.
- Also the GUI seems to have issues in this case (see printscreen)