Elastic Agent's eBPF tc filters override existing tc rules on policy change/restart

We are encountering an issue where existing Linux Traffic Control (`tc`) rules are being removed when the Elastic Agent policy change/restarts.

Our application servers use Linux `tc` with eBPF-based filters for network traffic shaping. These rules are attached to network interfaces to control and traffic management at the kernel level.

At the same time, Elastic Agent on Linux also uses eBPF programs (via `tc` filters and kernel hooks) to collect security telemetry.

Since both our traffic shaping stack and the Elastic Agent rely on eBPF programs attached via `tc` (specifically `TcFilter`), they share the same kernel-level attachment points on the network interfaces.

When the Elastic Agent restarts (e.g., due to:

* service restart
* policy updates from Fleet/Kibana

), it reinitialises its configuration and reloads its inputs. During this process, it detaches and reattaches its eBPF `tc` filters.

This operation appears to **flush or overwrite the existing `tc` filter chain** on the interface, which results in:

* Removal of pre-existing application-level traffic shaping rules
* Loss of traffic control enforcement

---

### Please clarify the following

1. Is this expected behavior when Elastic Agent attaches `tc` eBPF programs?
2. Is there a way to prevent Elastic Agent from flushing existing `tc` filters?
3. Can Elastic Agent be configured to:

* Use separate chains/handles, or
* Preserve existing filters on the interface?

---

### Environment

* OS: Debian 12.9
* Elastic Agent: 8.15.1
* Endpoint Security: Enabled