Tinkerbell LoadBalancerInterface doesn't set tink-stack srcInterface

In the release v0.21.0 it became possible to set Tinkerbell loadBalancerInterface. While it sets the vip_interface in kube-vip correctly to the specified interface, it doesn't change srcInterface variable from tink-stack deployment.

Snippet from the tink-stack deployment:

```yaml
- command:
- /bin/sh
- -c
- |
# This script allows us to listen and respond to DHCP requests on a host network interface and interact with Smee properly.
# This is used instead of `hostNetwork: true` because the dhcp relay requires clear paths for listening for broadcast traffic
# and sending/receiving unicast traffic to/from Smee.
set -xe
# if sourceInterface is not set use the interface from the default route
srcInterface=""
if [ -z "$srcInterface" ]; then
srcInterface=$(nsenter -t1 -n ip route | awk '/default/ {print $5}' | head -n1)
fi
# Create the interface. TODO: If this fails, try again with a different name?
nsenter -t1 -n ip link add macvlan0 link ${srcInterface} type macvlan mode bridge
# Move the interface into the POD.
pid=$(echo $$)
nsenter -t1 -n ip link set macvlan0 netns ${pid} || nsenter -t1 -n ip link delete macvlan0
# Set the interface up
ip link set macvlan0 up
# Set the IP address
ip addr add 127.1.1.1/32 dev macvlan0 noprefixroute || true
```

If the srcInterface in that script is not set, it defaults to the interface with default route, which breaks DHCP relaying unless it is changed manually.

**What happened**:
Variable srcInterface is not set to the same interface as Tinkerbell loadBalancerInterface variable.

**What you expected to happen**:
Variable srcInterface in tink-stack deployment config is set to the same value as Tinkerbell loadBalancerInterface variable.

**How to reproduce it (as minimally and precisely as possible)**:
1. Create cluster with Tinkerbell loadBalancerInterface set.
2. Observe the resulting tink-stack deployment config: `kubectl get deployments.apps -n eksa-system tink-stack -o yaml`.

**Environment**:
- EKS Anywhere Release: v0.21.1
- EKS Distro Release: 1.30

Reproduce the issue by creating a cluster with loadBalancerInterface set, then inspect the tink-stack deployment with kubectl get deployments.apps -n eksa-system tink-stack -o yaml. Trace how the loadBalancerInterface value reaches the deployment and compare it with srcInterface in the embedded shell script. Done means both values use the specified interface and DHCP relaying no longer falls back to the default route.

Written by the indexing model from the issue text.