Elastic-endpoint continues running after re-enrolling elastic-agent into a policy without EDR

[Harmlos]

Bug Description:

If an agent with the EDR integration is re-enrolled into a policy that does not include the EDR integration, the elastic-endpoint service continues running independently with the last applied configuration.

As a result:

• When the agent is removed, the EDR integration is not uninstalled and continues to run with its last configuration.
• Switching the agent to another policy that does not include EDR has no effect - the EDR service continues running with its pre-re-enrollment settings.
• If the agent is uninstalled after such a re-enrollment and then reinstalled, the EDR service remains and continues working with the previous settings.

In all these cases, until control over elastic-endpoint is restored, there are CPU usage spikes caused by the elastic-endpoint service.
It is impossible to determine which settings are causing the CPU spike since the agent itself no longer has the EDR integration.

Steps to Reproduce:

1. Create a policy Policy-install-without-edr without any integrations.
2. Create a policy Policy-test-with-edr with the EDR integration.
3. Install an agent using the API key of Policy-install-without-edr.
4. Assign the agent to Policy-test-with-edr.
5. Re-enroll the agent using the API key of Policy-install-without-edr.

At this point, the agent and EDR service are running independently on the host.

After reassigning the agent to Policy-test-with-edr again, control over elastic-endpoint is restored, and its behavior returns to normal.

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[cmacknz]

Do you have tamper protection enabled?

We have a test to make sure that defend can be removed regardless of tamper protection if it is explicitly removed from the agent policy.

elastic-agent/testing/integration/endpoint_security_test.go

Lines 336 to 338 in 535610a

	t.Logf("Removing Elastic Defend: %v", fmt.Sprintf("/api/fleet/package_policies/%v", pkgPolicyResp.Item.ID))
	_, err = info.KibanaClient.DeleteFleetPackage(ctx, pkgPolicyResp.Item.ID)
	require.NoError(t, err)

This should functionally be the same as a policy reassignment, but something could be going wrong with tamper protection specifically during re-assignment. Defend continuing to run like this is what I would expect if agent were trying to remove it without the correct uninstall token / correctly signed Fleet action.