[BUG] cidrHost/cidrSubnet fail during Bicep expansion when address prefixes are assigned outside the template

### Existing rule

N/A — this affects Bicep expansion rather than a specific rule.

### Description of the issue

When a virtual network, subnet, or IPAM pool gets its address prefixes assigned outside the template being analyzed, the `properties.addressPrefixes` value cannot be resolved during expansion. PSRule for Azure creates a generic mock for the unresolved reference, and unknown string properties on that mock resolve to an empty string.

The `cidr*()` functions validate their input strictly, so any expression that consumes such a value fails expansion of the whole deployment:

```text
The specified CIDR '' is not valid.
```

This is increasingly common with Azure Virtual Network Manager IPAM. The prefixes are allocated by IPAM at deploy time via `ipamPoolPrefixAllocations`, so they are genuinely not knowable from the source. Anything derived from them with `cidrHost()` or `cidrSubnet()` — a static private frontend IP for an Application Gateway is the typical case — cannot be analyzed at all today.

The generic mock already knows the resource type of the reference. That is enough to supply a well-formed placeholder for a small set of well-known address properties, so expansion can continue instead of failing outright.

Two related gaps make this worse than it first appears:

1. Existing (`existing = {}`) resources are registered as deployment symbols but are not added to the resource ID lookup, so `reference('vnet::subnet')` can fall back to a mock built from the bare symbolic name and lose the resource type entirely.
2. When a resource declares a partial `properties` object (for example a subnet that sets `ipamPoolPrefixAllocations` but not `addressPrefixes`), the properties are wrapped in a plain mock object. Resource type context is lost, so *missing sibling* properties cannot be inferred even when the type is known.

Importantly, a fix here should not relax the `cidr*()` functions themselves. Keeping them strict is what still catches genuine authoring mistakes such as passing `id` instead of an address prefix, or passing `addressPrefixes` without indexing it.

### Error messages

```text
Failed to expand bicep source 'deploy.bicepparam'. Exception calling "GetBicepParamResources" with "2" argument(s):
"Unable to expand resources because the source file 'deploy.bicepparam' was not valid.
The deployment 'root/example' with symbolic name 'example' failed.
An error occurred evaluating expression '[cidrHost(reference('vnet::subnet').addressPrefixes[0], 3)]'
at path 'properties.frontendIPConfigurations[1].properties.privateIPAddress'.
The function 'cidrHost' failed. The specified CIDR '' is not valid."
```

```text
An error occurred evaluating expression '[cidrSubnet(reference('networkManager::platformPool').addressPrefixes[0], 23, 0)]'.
The function 'cidrSubnet' failed. The specified CIDR '' is not valid."
```

### Reproduction

Both cases below fail expansion.

**Case 1 — subnet address prefix allocated by IPAM**

```bicep
targetScope = 'resourceGroup'

resource vnet 'Microsoft.Network/virtualNetworks@2024-05-01' existing = {
name: 'vnet-example'

resource subnet 'subnets' = {
name: 'ApplicationGatewaySubnet'
properties: {
ipamPoolPrefixAllocations: [
{
numberOfIpAddresses: '256'
pool: { id: '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg-example/providers/Microsoft.Network/networkManagers/vnm-example/ipamPools/pool-example' }
}
]
defaultOutboundAccess: true
}
}
}

// Fails: The specified CIDR '' is not valid.
output privateFrontendIP string = cidrHost(vnet::subnet.properties.addressPrefixes[0], 3)
```

**Case 2 — IPAM pool address prefix**

```bicep
targetScope = 'resourceGroup'

resource networkManager 'Microsoft.Network/networkManagers@2024-05-01' existing = {
name: 'vnm-example'

resource platformPool 'ipamPools' existing = {
name: 'pool-example'
}
}

// Fails: The specified CIDR '' is not valid.
output reservation string = cidrSubnet(networkManager::platformPool.properties.addressPrefixes[0], 23, 0)
```

The same failure occurs for a virtual network whose `properties.addressSpace.addressPrefixes` is IPAM-allocated.

### Version of PSRule

2.9.0

### Version of PSRule for Azure

1.48.0-B0231

### Additional context

A targeted fix would be to give the existing mock layer source awareness: a small table mapping resource type plus normalized property path to a typed placeholder, so only well-known address properties return a valid placeholder CIDR and everything else keeps today's behaviour.

Using the reserved documentation range from RFC 5737 (`192.0.2.0/24`) makes placeholders obvious in output and avoids colliding with plausible customer address space.

The minimal set that unblocks the IPAM scenarios:

- `Microsoft.Network/virtualNetworks` → `properties.addressSpace.addressPrefixes[]`
- `Microsoft.Network/virtualNetworks/subnets` → `properties.addressPrefix`
- `Microsoft.Network/virtualNetworks/subnets` → `properties.addressPrefixes[]`
- `Microsoft.Network/networkManagers/ipamPools` → `properties.addressPrefixes[]`

A table-driven approach keeps this easy to extend later to other resources that expose address-like outputs (network interfaces, public IPs, firewalls, DNS resolver inbound endpoints) without reworking the mock layer, and without requiring full ARM property schemas.

I have a working implementation of this and will follow up with a PR.

Start at GetBicepParamResources and trace the generic mock layer used when referenced resources cannot be resolved. Reproduce the two cidrHost/cidrSubnet failures, then verify that typed placeholders preserve expansion for the listed address properties while unrelated missing properties and strict CIDR validation retain their current behavior.

Written by the indexing model from the issue text.