[Bug] elasticstack_elasticsearch_security_api_key delete requires manage_api_key even when the key is owned by the calling user #4351

Describe the bug
Destroying (or replacing) an elasticstack_elasticsearch_security_api_key resource fails with a 403 unless the Elasticsearch user configured on elasticsearch_connection has the broad manage_api_key (or manage_security) cluster privilege. The manage_own_api_key privilege, which is documented as sufficient to create/manage API keys owned by the calling user, is not accepted.

This happens because DeleteAPIKey (internal/clients/elasticsearch/security_api_key.go) always calls the Invalidate API Key endpoint with an explicit ids list and never sets "owner": true:

_, err := typedClient.Security.InvalidateApiKey().Request(&invalidateapikey.Request{
    Ids: []string{id},
}).Do(ctx)

Per the Invalidate API Key API docs:

To use this API, you must have at least the manage_security, manage_api_key, or manage_own_api_key cluster privileges. The manage_security privilege allows deleting any API key, including both REST and cross cluster API keys. The manage_api_key privilege allows deleting any REST API key, but not cross cluster API keys. The manage_own_api_key only allows deleting REST API keys that are owned by the user. In addition, with the manage_own_api_key privilege, an invalidation request must be issued in one of the three formats:

1. Set the parameter owner=true.
2. Or, set both username and realm_name to match the user's identity.
3. Or, if the request is issued by an API key, that is to say an API key invalidates itself, specify its ID in the ids field.

Because the provider always sends ids alone without owner: true (and the calling credential is normally a user/service account, not an API key invalidating itself), none of the three manage_own_api_key request formats are satisfied, so Elasticsearch falls back to requiring manage_api_key.

To Reproduce
Steps to reproduce the behavior:

1. TF configuration used: an elasticstack_elasticsearch_security_api_key resource, with elasticsearch_connection pointed at a user/service account whose role only grants manage_own_api_key (plus whatever cluster privileges are needed to create the key, e.g. monitor).
2. TF operations to execute to get the error: terraform apply followed by terraform destroy (or any change that requires replacing the resource).
3. See the error in the output:

Error: status: 403, failed: [security_exception], reason: action
[cluster:admin/xpack/security/api_key/invalidate] is unauthorized for user
[build_queue_writer] with effective roles
[build_queue_writer,manage_own_api_keys,monitor_cluster], this action is
granted by the cluster privileges [manage_api_key,manage_security,all]

Expected behavior
When the resource's API key is invalidated, the provider should be able to authorize the request with manage_own_api_key alone (the same privilege that already covers create), by sending the invalidate request with owner: true (request format 1 above) rather than only ids.

Versions (please complete the following information):

• Provider: elasticstack_elasticsearch_security_api_key resource
• Elasticsearch Version: any version supporting the Invalidate API Key API's owner flag (added in 6.7.0)

Additional context
Affected code: internal/clients/elasticsearch/security_api_key.go (DeleteAPIKey), called from internal/elasticsearch/security/apikey/resource/delete.go and internal/elasticsearch/security/apikey/ephemeral/resource.go.

I'll open a PR that adds an optional owner attribute (default true) to the resource schema and threads it through to the Invalidate API Key request's owner flag.