Change Proposal: Add workflow, ai_agent, and ai_agent_tool asset types for integration packages

## Summary

Propose adding three new asset types to the integration package specification:

1. **`kibana/workflow/`** — Ship Elastic Workflow YAML definitions as integration assets
2. **`kibana/ai_agent/`** — Ship Agent Builder configurations as integration assets
3. **`kibana/ai_agent_tool/`** — Ship custom AI agent tool definitions as integration assets

These would allow integrations to deliver end-to-end automated detection, triage, and response capabilities rather than just detection rules and dashboards.

## Problem Statement

Elastic Workflows (Preview, 9.3) and Agent Builder (GA, 9.3) are powerful automation primitives that complete the detect → triage → respond loop within the stack. However, integration packages cannot currently ship any of these asset types.

This creates a gap: an integration can ship detection rules that generate alerts, but cannot ship the workflow that triages those alerts, the AI agent that performs initial investigation, or the custom tools that agent needs to do its job. Users must manually recreate these automations after installing every integration, which:

- Reduces time-to-value for integrations that depend on post-detection automation
- Prevents integration authors from shipping opinionated, tested automation alongside their detection content
- Creates inconsistency between what the stack supports natively and what integrations can deliver

### Concrete use case: Insider Threat Detection

We are building an insider threat detection integration that uses `semantic_text` fields and ES|QL `MATCH` queries to detect credential sharing, data exfiltration, sabotage intent, and other threat categories in email and messaging data.

The integration needs to ship:

1. **Detection rules** (supported today) — ES|QL rules with semantic MATCH queries against exemplar threat phrases
2. **A scheduled workflow** (not supported) — Reads threat exemplar phrases from a user-managed index, generates/updates detection rules so teams can add or remove exemplars without editing rule queries directly
3. **Custom agent tools** (not supported) — ES|QL and search tools for exemplar lookup, user risk scoring, correlated activity queries, and case creation
4. **An AI agent** (not supported) — Triggered by alert workflow, performs initial triage of insider threat alerts using the custom tools above, examining matched email/message content, user risk history, and correlated behavioural signals, then writes investigation notes to a Security case

Without workflow, agent, and tool packaging, steps 2–4 must be manually configured by every user post-install, which significantly reduces the integration's value.

## Proposed Changes

### 1. `kibana/workflow/` asset type

**Directory structure:**
```
kibana/
workflow/
-.yml
```

**Behaviour on install:**
- Kibana imports the workflow definition (same as creating via the Workflows UI/API)
- Workflow is installed in a disabled state by default (user enables after reviewing)
- Workflow triggers, connectors, and referenced indices are validated at install time

**Behaviour on upgrade:**
- Same semantics as other Kibana assets — updated if not user-modified, or flagged for review

**Behaviour on uninstall:**
- Workflow is removed (or disabled, consistent with how security rules are handled)

### 2. `kibana/ai_agent_tool/` asset type

**Directory structure:**
```
kibana/
ai_agent_tool/
-.json
```

**Contents:** Custom tool definitions that agents can invoke, including:
- Tool name and description (used by the LLM for tool selection)
- Tool type (e.g., `workflow`, `esql_query`, `elasticsearch_search`, `index`, `connector`)
- Configuration (which workflow to invoke, which index to query, query template, etc.)
- Input schema (parameters the agent passes to the tool)
- Output mapping (how tool results are returned to the agent)

### 3. `kibana/ai_agent/` asset type

**Directory structure:**
```
kibana/
ai_agent/
-.json
```

**Contents:** Agent Builder configuration including:
- Agent name and description
- System prompt / instructions
- Tool references (list of `ai_agent_tool` assets this agent uses, by ID)
- Knowledge source references (index patterns the agent can query)
- LLM provider configuration (or reference to a configured connector)

**Behaviour on install:**
- Tools are installed first (dependency ordering: tools → agents → workflows)
- Agent configuration is created in Agent Builder with tool references resolved
- Agent is available but not automatically invoked (user must wire triggers)

**Behaviour on upgrade:**
- Agent configuration is updated if not user-modified

**Behaviour on uninstall:**
- Agent and associated tools are removed

## Impact on Elastic Stack Components

| Component | Changes needed |
|---|---|---|
| **package-spec** | Add `kibana/workflow`, `kibana/ai_agent`, and `kibana/ai_agent_tool` folder specs with JSON Schema validation |
| **Kibana (Fleet)** | Import/export handlers for all three asset types during package install/upgrade/uninstall. Install ordering: tools → agents → workflows (since workflows may reference agents, and agents reference tools) |
| **elastic-package** | Validation support for new asset types, dependency resolution between agent/tool assets, test framework extensions |
| **Kibana (Workflows)** | Stable import/export API for workflow definitions |
| **Kibana (Agent Builder)** | Export/import API for agent configurations and custom tool definitions |

## Alternatives Considered

1. **Ship workflows/agents as documentation only** — Users manually create them from README instructions. This is the current workaround used by DGA/ProblemChild integrations for their manual `@custom` pipeline hookup steps. It works but doesn't scale.

2. **Post-install setup script** — A script that calls the Kibana API to create workflows, tools, and agents. This bypasses Fleet's lifecycle management (upgrade, uninstall) and creates orphaned resources.

3. **Ship only detection rules** — Limits integrations to the detect phase only, ignoring the triage and respond capabilities now available in the stack.

## Prior Art

The package-spec has successfully added new Kibana asset types in recent versions:
- `alerting_rule_template` (spec 3.5.0)
- `slo_template` (spec 3.5.6)
- `esql_view` (spec 3.6.0, under `elasticsearch/`)

This proposal follows the same pattern of extending the spec as the stack's capabilities grow.

## Checklist

Per the Change Proposal process:
- [ ] Consensus from Workflows team on import/export API stability
- [ ] Consensus from Agent Builder team on configuration and tool export format
- [ ] Kibana Fleet: implement install/upgrade/uninstall handlers for all three asset types
- [ ] package-spec: add folder specs and JSON Schema definitions
- [ ] elastic-package: add validation, dependency resolution, and test support
- [ ] Documentation updates