[Feature Request]: Separate SubnetIds for Login Node NLB and EC2 Instances

Currently, `LoginNodes → Pools → Networking → SubnetIds` is used for **both** the Network Load Balancer placement and the login node EC2 instance placement. This prevents implementing the standard AWS architecture pattern of an internet-facing NLB in a public subnet forwarding traffic to EC2 instances in private subnets.

## Expected Behavior

Allow specifying separate subnets for the NLB and the login node instances, for example:

```yaml
LoginNodes:
Pools:
- Name: cfd-login
Count: 1
InstanceType: t3.large
Networking:
LoadBalancerSubnetIds:
- subnet-public-xxx # NLB placed here (internet-facing)
SubnetIds:
- subnet-private-xxx # EC2 instances placed here (no public IP)

```

This would enable the architecture:

```
Internet → Public NLB (public subnet) → Login Node EC2 (private subnet)

```

## Current Behavior

`SubnetIds` controls both the NLB and instance placement:

- **Private subnet** → NLB becomes `internal`, instances are in private subnet
- **Public subnet** → NLB is `internet-facing`, but instances are also placed in the public subnet

There is no way to decouple these, resulting in either:

1. Instances unnecessarily exposed in public subnets, or
2. An internal-only NLB requiring a bastion/VPN for access

## Use Case

This is a standard AWS networking pattern used widely across ELB-backed services (ECS, EKS, EC2 Auto Scaling). The [AWS prescriptive guidance on load balancer subnets](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-balancer-stickiness/subnets-routing.html) documents this as a recommended architecture:

- NLB in public subnets (receives internet traffic)
- Target instances in private subnets (no direct internet exposure)
- NAT Gateway in public subnet for outbound-only internet access from instances

For HPC clusters that need to provide SSH access to external users (collaborators, researchers) while keeping login nodes hardened in private subnets, this separation is essential for security best practices.

## Proposed Solution

Add an optional `LoadBalancerSubnetIds` (or `ElasticLoadBalancerSubnetIds`) parameter under `LoginNodes → Pools → Networking`:

```yaml
LoginNodes:
Pools:
- Name: my-pool
Networking:
SubnetIds:
- subnet-private-xxx # For EC2 instance placement
LoadBalancerSubnetIds:
- subnet-public-xxx # For NLB placement (optional)
SecurityGroups:
- sg-xxx

```

Start by tracing how LoginNodes → Pools → Networking → SubnetIds is parsed and used for NLB and login-node EC2 placement. Identify the validation and deployment paths, then verify that an optional LoadBalancerSubnetIds value separates the placements while existing SubnetIds behavior remains unchanged.

Written by the indexing model from the issue text.