HAProxy frontend extaddr field rejects the dynamic per-interface bind addresses the GUI supports (breaks dynamic-IP WANs) #947

Is your feature request related to existing pfSense functionality that is missing from the API? Please describe.
Yes — Services > HAProxy > Settings > Frontend > <edit> > External address. In the GUI this dropdown includes one entry per configured interface (e.g. "WAN address (IPv4)"), which binds the listener to that interface's current IP, re-resolved on every config reload. New frontends created in the GUI default to this option (haproxy_listeners_edit.php sets $new_item['extaddr'] = "wan_ipv4"; for a new listener). The REST API exposes the same field (a_extaddr[].extaddr on /api/v2/services/haproxy/frontend) but its documented enum only allows custom, any_ipv4, any_ipv6, localhost_ipv4, localhost_ipv6 — any interface-specific value like wan_ipv4 is rejected with FIELD_INVALID_CHOICE.

Is your feature request related to a problem? Please describe.
I'm always frustrated when I have to hardcode a literal IP for a HAProxy frontend bound to a WAN with a dynamic address (DHCP or, in my case, PPPoE) via the API, because the real dropdown option that avoids this (wan_ipv4) isn't in the accepted enum. Confirmed the backend/renderer has no problem with this value — I set it directly via config_set_path() / write_config() + haproxy_configure() over SSH as a workaround, HAProxy reloaded clean and bound to the interface's live IP, and the REST API's own GET on that frontend reflects the value back without complaint. It's only the API's write path (POST/PATCH) that blocks it. Concretely: my WAN IP changed (PPPoE reconnect) and every frontend using custom + a hardcoded IP silently stopped binding to anything, with no way to fix it back through the API.

Describe the solution you'd like
Generate the extaddr enum (and accept it on write) from the same source the GUI dropdown already uses — haproxy_get_bindable_interfaces() in /usr/local/pkg/haproxy/haproxy_utils.inc — so <realif>_ipv4/<realif>_ipv6 (e.g. wan_ipv4, lan_ipv4) are valid values for every configured interface, matching what a fresh GUI-created listener already defaults to.

Describe alternatives you've considered

• custom + a hardcoded literal IP — works until the WAN IP changes, then requires manual intervention (a PATCH call) every time.
• any_ipv4 (0.0.0.0) — binds on all interfaces including LAN, which on my setup conflicts with the webConfigurator/REST API's own listener on the LAN interface. Not viable when the box is also managed from LAN.
• Direct config.xml manipulation over SSH (config_get_path/config_set_path/write_config, then haproxy_configure() to apply) — works, but defeats the purpose of having a REST API for this at all.

Additional context

• Versions: pfSense 2.9.0-RELEASE (FreeBSD 16.0-CURRENT), pfSense-pkg-RESTAPI 2.10_2, pfSense-pkg-haproxy 0.65.7 (haproxy 3.2.19).
• Example of a currently-rejected request:

  PATCH /api/v2/services/haproxy/frontend
  {"id": 0, "a_extaddr": [{"extaddr": "wan_ipv4", "extaddr_port": "443"}]}
  

  Response: {"code":400,"status":"bad request","response_id":"FIELD_INVALID_CHOICE","message":"Field \a_extaddr` encountered a nested validation error: Field `extaddr` must be one of [custom, any_ipv4, any_ipv6, localhost_ipv4, localhost_ipv6]","data":[]}`
• Workaround used (for anyone else hitting this before it's fixed):

  require_once("config.inc"); require_once("functions.inc");
  $p = "installedpackages/haproxy/ha_backends/item/<N>/a_extaddr/item/0"; // "ha_backends" holds frontends in this package's XML, not backends
  $e = config_get_path($p); $e["extaddr"] = "wan_ipv4"; $e["extaddr_custom"] = "";
  config_set_path($p, $e);
  write_config("HAProxy: switch external address to dynamic WAN interface IP");
  require_once("/usr/local/pkg/haproxy/haproxy.inc"); haproxy_configure();