[Auditd]: event.action is could be something valuable and ( event.outcome, event.type, event.category is missing )

### Integration Name

Auditd Logs [packages/auditd]

### Dataset Name

auditd.log

### Integration Version

3.23.2

### Agent Version

8.16.5

### Agent Output Type

logstash

### Elasticsearch Version

9.3.3.

### OS Version and Architecture

Oracle Linux Server (86_64)

### Software/API Version

NA

### Error Message

no error.message

### Event Original

type=PATH msg=audit(1785929023.259:25982789): item=1 name=""dummy_file"" inode=6910 dev=fd:05 mode=0100640 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:var_log_t:s0 nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID=""root"" OGID=""root""

### What did you do?

Source Host -> Elastic Agent -> Logstash -> Kafka -> Logstash -> Elasticsearch

### What did you see?

During analysis of PATH audit events, we observed that the event contains information indicating a file deletion operation:

nametype=DELETE

However, the parsed document does not populate ECS event classification fields such as:

event.category
event.type
event.outcome

event.action is populated but it could be more meaning full and valuable. currently its just "PATH"

As a result, the document contains file-related metadata, but lacks ECS event classification fields that would help identify the nature and outcome of the activity.

Since the audit record clearly indicates a delete-related operation through nametype=DELETE, we expected the event to be classified accordingly.

### What did you expect to see?

We expected the ingestion pipeline to populate applicable ECS event fields based on the information available in the audit record.

The exact ECS mapping can be determined by the Elastic team, but we would expect the event to be classified using the available audit context rather than leaving these event classification fields empty.

### Anything else?

We understand that a PATH record may be only one part of a larger audit event and that event classification may depend on associated records such as SYSCALL.

However, from our perspective, the audit event contains sufficient information to identify that the activity is related to a file deletion operation. Therefore, we would expect ECS fields such as:

event.action
event.category
event.type
event.outcome

to be populated when possible.

We would like the Elastic team to review whether the current behavior is expected or if additional ECS mappings should be applied for PATH records and related audit events.

Start in packages/auditd and review how PATH records are parsed and mapped to ECS fields. Compare the emitted document with event.action, event.category, event.type, and event.outcome, and check whether associated SYSCALL records are required. Done means the expected fields are populated when the available audit context supports them, with coverage for the reported deletion event.

Written by the indexing model from the issue text.