feat(azure): Network gateway, Virtual WAN and Bastion family (7 resource types)

[naxty]

Adds the Microsoft.Network gateway / Virtual WAN / Bastion family — 7 resource
types, all on ARM API version 2023-05-01 via
armnetwork/v4. This is the plugin's first hybrid connectivity: before this
there was no VPN, no Virtual WAN and no Bastion, only the standalone
LocalNetworkGateway.

Base is naxty/wave1-plumbing (PR #125), which carries the seven clients these
resources bind to. No shared file was touched — pkg/client/client.go,
common.go, armid.go, go.mod, README.md, .github/** and
pkg/registry/registry.go are all untouched; the resources self-register via
init().

Resource types

Formae type	ARM type	Client	Shape
AZURE::Network::VirtualWan	Microsoft.Network/virtualWans	VirtualWansClient	LRO CUD, free, seconds
AZURE::Network::VirtualHub	Microsoft.Network/virtualHubs	VirtualHubsClient	LRO CUD, billed, ~10 min each way
AZURE::Network::VpnSite	Microsoft.Network/vpnSites	VPNSitesClient	LRO CUD, free, seconds
AZURE::Network::VpnGateway	Microsoft.Network/vpnGateways	VPNGatewaysClient	LRO CUD, billed, ~30 min each way
AZURE::Network::BastionHost	Microsoft.Network/bastionHosts	BastionHostsClient	LRO CUD, billed, ~10 min each way
AZURE::Network::VirtualNetworkGateway	Microsoft.Network/virtualNetworkGateways	VirtualNetworkGatewaysClient	LRO CUD, billed, 30-45 min each way
AZURE::Network::VirtualNetworkGatewayConnection	Microsoft.Network/connections	VirtualNetworkGatewayConnectionsClient	LRO CUD, free, minutes

Every one copies the NetworkLocalNetworkGateway template verbatim: a fooAPI
interface over the SDK client, buildPropertiesFromResult, armIDParts,
normalizeAzureLocation + canonicalizeEnum on the read path,
isDeleteSuccessError for idempotent delete, encodeLROStart /
statusLRO / statusDeleteLRO for resume tokens, and the pending-poller branch
that pins the expected ARM path while the operation is in flight. Update is a
re-PUT everywhere (UpdateTags cannot reach any of the interesting fields).

Fixture runtime — please read before adding these to the matrix

These are the slowest resources in the plugin. FORMAE_TEST_TIMEOUT defaults to
5 minutes, which is not close to enough for four of the seven.

Fixture	Chain	Wall clock, one CRUD lifecycle
virtual-wan	rg -> WAN	< 2 min, free
vpn-site	rg -> WAN -> site	< 2 min, free
virtual-hub	rg -> WAN -> hub	~20-25 min, billed
bastion-host	rg -> vnet -> AzureBastionSubnet + Standard static PIP -> host	~20-25 min, billed
vpn-gateway	rg -> WAN -> hub -> gateway (+ free site for the connection)	~60 min, billed
virtual-network-gateway	rg -> vnet -> GatewaySubnet + PIP -> gateway	~60-90 min, billed
virtual-network-gateway-connection	the above plus LocalNetworkGateway + connection	~60-90 min, billed

Recommendation for .github/conformance-matrix.txt (orchestrator's call, I did
not edit the file):

• Add unconditionally: virtual-wan, vpn-site — free and fast.
• Add with a TIMEOUT override: virtual-hub, bastion-host, in the style
  the Front Door entries already use.
• Exclude with a cost comment: vpn-gateway, virtual-network-gateway,
  virtual-network-gateway-connection. Suggested wording, matching the
  cdn-* and certificate exclusions already in the file:

# vpn-gateway, virtual-network-gateway and virtual-network-gateway-connection
# excluded: these are the slowest and most expensive resources in the plugin.
# A VirtualNetworkGateway takes 30-45 min to create and the same to delete; a
# Virtual WAN VPN gateway ~30 min each way, on top of a ~10 min hub. One CRUD
# lifecycle is 60-90 min of billed gateway time per fixture. CRUD is validated
# via test-integration (mocked) plus the marshaller assertions in each
# <resource>_integration_test.go. Run live locally with a raised timeout:
#   FORMAE_TEST_TIMEOUT=90m make conformance-test-crud TEST=virtual-network-gateway
#   FORMAE_TEST_TIMEOUT=90m make conformance-test-crud TEST=virtual-network-gateway-connection
#   FORMAE_TEST_TIMEOUT=90m make conformance-test-crud TEST=vpn-gateway

The conformance-tests job's timeout-minutes: 120 would also need raising if
virtual-network-gateway-connection were ever added.

Correctness notes worth reviewing

Native-ID pinning. The highest-consequence path here. Every write returns
expectedNativeID on the in-progress branch, built from
config.SubscriptionId + resource group + name against the real ARM provider
path, and each resource has a PendingCreateReportsRealNativeID test asserting
the pending native ID equals the ID ARM actually assigns. A mismatch on a
45-minute gateway create orphans a billed resource for the whole window.

Load-bearing subnet names. Azure only accepts GatewaySubnet for a
VirtualNetworkGateway and AzureBastionSubnet for a BastionHost, and
rejects anything else after minutes of provisioning. Both resources check the
subnet ID's last segment before the request goes out and fail with a specific
message; both are documented on the subnetId field in the schema; both
fixtures create the subnet with the exact required name. lastARMSegment is a
small shared helper defined in bastionhost.go.

Service-populated values dropped on read. Nested hasProviderDefault does
not work, so anything Azure assigns inside a nested object is dropped rather
than compared:

• bgpSettings.bgpPeeringAddress / .bgpPeeringAddresses on both gateways —
  Azure allocates these out of the hub prefix / GatewaySubnet.
• sku.capacity on VirtualNetworkGateway.
• ipConfigurations[].privateIPAddress, and the per-child id / etag /
  type / provisioningState on every nested list (vpnSiteLinks,
  connections, ipConfigurations, vpnClientRootCertificates).
• VpnGateway.connections[].vpnLinkConnections (Azure seeds one per remote
  link), connectionStatus, byte counters.
• VirtualWan's virtualHubs / vpnSites back-references — the hub and site
  own their side of the reference.
• VirtualHub's routingState, virtualRouterAsn, virtualRouterIPs and the
  azureFirewall / vpnGateway / p2sVpnGateway / bgpConnections pointers.
• BastionHost.dnsName.
• On VirtualNetworkGatewayConnection, ARM types virtualNetworkGateway1,
  virtualNetworkGateway2 and localNetworkGateway2 as whole gateway
  objects, not SubResources, and inflates them on read. The plugin sends only
  their id and reads back only their id.

Each is covered by a Read_drops_service_state subtest.

Secrets. VirtualNetworkGatewayConnection.sharedKey and
.authorizationKey, VpnGateway.connections[].sharedKey and
VirtualNetworkGateway.vpnClientConfiguration.radiusServerSecret are all
writeOnly = true and typed (formae.Value|String). ARM does return the
connection's shared key on Get; the read path never emits it, and the tests
assert the literal key text is absent from the properties JSON.

Renamed fields. VirtualWan.virtualWanTier maps to ARM's
properties.type; renamed because the flattened property map already carries
the resource's own type. Cross-resource references use the repo's existing
fooId convention (virtualWanId, virtualHubId, subnetId,
publicIpAddressId, virtualNetworkGateway1Id, ...), matching
firewallPolicyId / publicIPAddressId on ApplicationGateway.

createOnly calls. gatewayType, vpnType, vpnGatewayGeneration,
connectionType, all three connection peer fields, virtualWanId,
virtualHubId, addressPrefix, VirtualHub.sku, BastionHost.sku,
VpnGateway.bgpSettings (ASN is immutable once set),
VpnGateway.isRoutingPreferenceInternet, and both gateways'
ipConfigurations (ARM cannot swap a front end in place). SKU on
VirtualNetworkGateway is not createOnly — resize within a family is a real
in-place update, exercised by the unit test.

Deliberately left out

• VpnGateway.natRules and VirtualHub route tables / hub connections.
  Separate ARM child types with their own clients; out of scope for this batch.
• vpnClientConfiguration in the virtual-network-gateway fixture.
  Point-to-site needs real root-certificate data or a RADIUS secret
  (write-only), neither of which the conformance harness round-trips. The full
  marshalling path is asserted in TestVirtualNetworkGateway_CRUD.
• connections[].sharedKey in the vpn-gateway fixture. Write-only nested
  inside an array — the harness cannot strip those, the same limitation the
  application-gateway fixture documents for sslCertificates[].data. Azure
  generates a key when it is omitted. The top-level
  VirtualNetworkGatewayConnection.sharedKey is exercised, since top-level
  write-only fields are handled (as acr-webhook shows).
• VirtualWan.allowVnetToVnetTraffic and
  VirtualHub.allowBranchToBranchTraffic in the fixtures. Both are in the
  schema, but Virtual WAN does not honour them in the way ARM echoes them back,
  so declaring them would compare against a value the service ignores.
• ExpressRoute circuits. connectionType = "ExpressRoute" and peerId are
  modelled and validated, but no ExpressRouteCircuit resource type exists yet
  and creating one requires a provider order, so there is no fixture.
• Developer-SKU Bastion (networkAcls, virtualNetwork) — not in the
  armnetwork/v4 SKU enum.

Verification

Run in the worktree on the final commit:

$ gofmt -l pkg schema
(no output)

$ go build ./...
Go build: Success

$ go test ./pkg/...
Go test: 1161 passed in 6 packages

$ make lint
golangci-lint run
0 issues.

$ make verify-schema
Status: PASSED
- Total modules: 156
- Total resource types: 155
- Duplicate files found: 0
- Duplicate types found: 0
VERIFICATION PASSED - Schema is valid

155 resource types = the 148 on the base branch plus these 7. All 14 fixture
files also evaluate cleanly under pkl eval --project-dir testdata.

Conformance was not run: no command in this branch touched real Azure.