UnitChangeModified triggered on units that are not changed creating wierd statuses on Kibana

## Scenario

Scenario where there is an agent policy with an existing package policies with some input [ cel for ex., ]. The status of integrations looks like

But when a package is added / removed from the agent policy then the input status are in wierd state.

## What's happening

When 1 out of 3 package policies is removed from the agent policy [syncUnits](https://github.com/elastic/elastic-agent-client/blob/main/pkg/client/client_v2.go#L653C20-L653C29) seems to be called and a [UnitChangeModified](https://github.com/elastic/elastic-agent-client/blob/main/pkg/client/client_v2.go#L716-L720) is triggered on existing units [ Although nothing has changed ].

When it reaches [beats listener](https://github.com/elastic/beats/blob/main/x-pack/libbeat/management/managerV2.go#L517-L518), an [updateUnit](https://github.com/elastic/beats/blob/main/x-pack/libbeat/management/managerV2.go#L415) on the unit concerned is triggered leading to a status of `Configuring` and Agent health shown `Healthy`.

Although there are no changes on the units, since a UnitChanged is triggered beat [input recalculates the status of all the input units and streams associated](https://github.com/elastic/beats/blob/main/x-pack/libbeat/management/unit.go#L263-L289) and triggers another UpdateState on the clientUnit.

Not sure if this is a bug or intended with the current design between agent-client and beats.

cc: @cmacknz @andrewkroh

Start in pkg/client/client_v2.go at syncUnits and the UnitChangeModified trigger, then trace the beats listener in x-pack/libbeat/management/managerV2.go and status handling in x-pack/libbeat/management/unit.go. Reproduce removing one package policy from an agent policy with existing inputs, determine whether unchanged units should emit updates, and verify that their statuses no longer enter the reported intermediate states.

Written by the indexing model from the issue text.