feat(bnk/cneinstance): auto-create F5BnkGateway chassis CR for AWS/EKS

[JLCode-tech]

Summary

DRAFT — encodes the F5BnkGateway chassis recipe verified on aws-syd-test (see project_aws_syd_test_tmm_kernelmode_break.md in agent memory). Cannot fresh-deploy validate from this session; promoting from draft requires running a fresh AWS deploy and confirming the gateway works first-try.

Despite F5 docs saying F5BnkGateway is optional, in f5ingress:v14.19.4-0.1.36 it is the trigger that activates the entire Gateway translation pipeline on AWS/EKS. Without this CR, the controller logs Watched application namespaces: [] and silently ignores all Gateway + HTTPRoute CRs even when CNEInstance shows Programmed=True. Discovery trail across 3 sessions is captured in the agent memory note.

What changed

• bnk/cneinstance/main.tf (+61) — new null_resource.f5_bnkgateway_chassis. Mirrors the existing null_resource.cloud_network_mapping pattern (gated count on input non-empty, matching destroy provisioner). Created in var.instance_namespace (controller's namespace).
• bnk/cneinstance/variables.tf (+28) — new bnk_gateway_chassis variable (object: optional name defaulting to bnk-gateway-chassis, plus default_listener_networks list of {name, start_address, end_address}). Empty list = skip CR creation. Comments call out the explicit-address requirement (the CRD's ipv4BaseCidr alternative is rejected by the controller runtime: "IPRange error: start/end IP addresses do not match IPv4 family").
• bnk/cneinstance/bnkforge.pack.json (+9) — register the new variable so forge's catalog CI gate (ci: validate every bnkforge.pack.json against forge contract #51) recognizes it.

Verification recipe (when ready to promote from draft)

Apply the module to a fresh AWS/EKS cluster with:

bnk_gateway_chassis = {
  default_listener_networks = [
    {
      name          = "external-net"
      start_address = "10.0.11.100"
      end_address   = "10.0.11.200"
    }
  ]
}
cloud_provider           = "aws"
cloud_az_subnet_mappings = [
  {
    az = "ap-southeast-2b"
    subnets = [
      { cidr = "10.0.11.0/24", subnet_id = "subnet-..." },
      { cidr = "10.0.21.0/24", subnet_id = "subnet-..." },
    ]
  }
]

Then deploy a Gateway + HTTPRoute and verify:

• kubectl -n f5-operator get f5-bnkgateways shows bnk-gateway-chassis with Programmed=True
• kubectl -n f5-operator logs deploy/f5-cne-controller | grep "Watched application namespaces" shows [default] (or your app ns), NOT []
• curl http://<gateway-vip>/v1/... returns the actual backend response, not a TCP timeout

Out of scope (separate followup PRs)

• infra/aws/cne-irsa module — IRSA + allow-ec2-vip IAM policy (followup_cne_irsa_module.md)
• tmm-init ConfigMap for static client/backend subnet routes (followup_tmm_init_routes_configmap.md)
• bnk-vlans ENI fix — len(existing_enis) >= 3 skip-guard in infra/aws/high-performance-nodes/scripts/eni_attachment_manager.py
• TMM kernel-mode conversion — runtime hot-conversion currently, would need full RFC

These are tracked in agent memory followup notes for future PRs.

Backwards compat

Existing on-prem callers don't pass bnk_gateway_chassis → empty default_listener_networks → count = 0 → null_resource skipped → no behavior change. Only AWS/EKS callers that explicitly opt in see the new chassis CR creation.

[JLCode-tech]

Superseded by the new AWS catalog repo. The F5BnkGateway chassis auto-create logic is now part of bnk-forge-catalog-aws-eks/modules/eks-cluster-cneinstall (see PR #8), bundled with the rest of the AWS-specific CNEInstance + IRSA install.

Per the catalog repo migration, AWS-specific concerns live in the per-cloud catalog repo from now on. Closing this PR without merge — branch fix/cneinstance-bnkgateway-chassis-eks can be deleted.