[bug-hunter] add_agent_metadata processor rejects valid partial configs

## Impact
Users configuring the `add_agent_metadata` processor with only one optional section (`data_stream` or `elastic_agent`) get a hard startup/config error, even though the processor implementation and tests support either section independently. This blocks valid configurations and can prevent Beats startup.

## Reproduction Steps
1. From repo root, create and run this minimal repro:

```go
package main

import (
"fmt"

"github.com/elastic/beats/v7/libbeat/processors"
_ "github.com/elastic/beats/v7/libbeat/processors/actions"
conf "github.com/elastic/elastic-agent-libs/config"
"github.com/elastic/elastic-agent-libs/logp/logptest"
)

func run(yml string) {
cfg, err := conf.NewConfigWithYAML([]byte(yml), "repro")
if err != nil {
fmt.Printf("config parse error: %v\n", err)
return
}
_, err = processors.New([]*conf.C{cfg}, logptest.NewTestingLogger(nil, ""))
if err != nil {
fmt.Printf("processors.New error: %v\n", err)
return
}
fmt.Println("processors.New success")
}

func main() {
fmt.Println("Case A: data_stream only")
run(`add_agent_metadata:
data_stream:
dataset: system.cpu
namespace: default
type: metrics`)

fmt.Println("Case B: elastic_agent only")
run(`add_agent_metadata:
elastic_agent:
id: agent-123
snapshot: false
version: 9.3.0`)
}
```

2. Run:

```bash
go run /tmp/gh-aw/agent/repro_add_agent_metadata.go
```

3. Observed output:

```text
Case A: data_stream only
processors.New error: missing elastic_agent option in add_agent_metadata
Case B: elastic_agent only
processors.New error: missing data_stream option in add_agent_metadata
```

## Expected vs Actual
**Expected:** `add_agent_metadata` should accept configs with only `data_stream` or only `elastic_agent` when users only need one of these metadata blocks.

**Actual:** processor registration enforces both sections as required and fails config loading with `missing ... option` errors.

## Failing Test
A minimal failing test can assert that `processors.New` succeeds for either of these configs:
- `add_agent_metadata` with only `data_stream`
- `add_agent_metadata` with only `elastic_agent`

Today both fail during config validation.

## Evidence
- Plugin registration requires both fields:
- `libbeat/processors/actions/add_agent_metadata.go:27-29`
- Implementation treats both sections as optional (`nil` checks and conditional updates):
- `libbeat/processors/actions/addagentmetadata/add_agent_metadata.go:70-89`
- `libbeat/processors/actions/addagentmetadata/add_agent_metadata.go:91-107`
- Existing tests explicitly verify optional behavior for each section:
- `libbeat/processors/actions/addagentmetadata/add_agent_metadata_test.go:116-165`
- Direct constructor path works with partial config (showing core processor logic is valid), while registry path rejects it (reproduction output above).

> [!NOTE]
>
> 🔒 Integrity filtering filtered 1 item
>
> Integrity filtering activated and filtered the following item during workflow execution.
> This happens when a tool call accesses a resource that does not meet the required integrity or secrecy level of the workflow.
>
> - issue:elastic/beats#unknown (`search_issues`: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".)
>
>

---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Bug Hunter](https://github.com/elastic/beats/actions/runs/23846030995)

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
> - [x] expires on Apr 8, 2026, 11:44 AM UTC

Start in libbeat/processors/actions/add_agent_metadata.go:27-29 and compare its plugin registration with the optional-section handling in libbeat/processors/actions/addagentmetadata/add_agent_metadata.go:70-107. Review add_agent_metadata_test.go:116-165, then add or update coverage for processors.New with each partial configuration. Done means both configurations load successfully without breaking existing tests.

Written by the indexing model from the issue text.