Feature request: Support workflow, ai_agent, and ai_agent_tool asset types in integration packages

## Summary

Request support in `elastic-package` for building, validating, and testing three new asset types in integration packages:

1. **`kibana/workflow/`** — Elastic Workflow YAML definitions
2. **`kibana/ai_agent/`** — Agent Builder configurations
3. **`kibana/ai_agent_tool/`** — Custom AI agent tool definitions

Related package-spec Change Proposal: https://github.com/elastic/package-spec/issues/1143

## Motivation

Elastic Workflows (Preview, 9.3) and Agent Builder (GA, 9.3) are now core stack capabilities, but integration packages cannot ship either. This forces users to manually recreate automations after installing integrations that depend on post-detection workflows or AI-assisted triage.

### Concrete use case

We are building an insider threat detection integration that uses `semantic_text` fields and ES|QL `MATCH` queries. The integration needs to ship:

- **Detection rules** (supported today) — ES|QL rules with semantic MATCH queries
- **A scheduled workflow** (not supported) — Reads threat exemplar phrases from a user-managed index and generates/updates detection rules, so teams can manage exemplars without editing rule queries
- **Custom agent tools** (not supported) — ES|QL and search tools for exemplar lookup, user risk scoring, correlated activity queries, and case creation
- **An AI agent** (not supported) — Triggered by an alert workflow, performs initial triage of insider threat alerts using the custom tools, then writes investigation notes to a Security case

Without support for these asset types, steps 2–4 must be manually configured by every user, significantly reducing the integration's value.

## What needs to happen in elastic-package

### Build support
- Recognise `kibana/workflow/`, `kibana/ai_agent/`, and `kibana/ai_agent_tool/` directories during `elastic-package build`
- Include these assets in the built package archive

### Validation support
- Validate workflow YAML against a schema (once defined in package-spec)
- Validate agent and tool JSON against a schema
- Validate dependency ordering: tools must exist before agents that reference them, agents before workflows that invoke them

### Test support
- `elastic-package test` should verify that workflow, agent, and tool assets can be installed into a running Kibana instance
- Verify that workflows can be enabled and triggered
- Verify that agents can be invoked with their configured tools

## Proposed asset structure

```
my_integration/
kibana/
workflow/
-.yml # Workflow YAML definition
ai_agent_tool/
-.json # Custom tool definition
ai_agent/
-.json # Agent Builder configuration
```

### Workflow asset contents
Standard Elastic Workflow YAML format with `name`, `description`, `triggers`, `steps`, `consts`, and `inputs` sections.

### Agent tool asset contents
```json
{
"name": "tool-name",
"description": "Description used by LLM for tool selection",
"type": "esql_query | elasticsearch_search | workflow | connector",
"configuration": { },
"input_schema": { },
"output_mapping": { }
}
```

### Agent asset contents
```json
{
"name": "agent-name",
"description": "Agent description",
"system_prompt": "Instructions for the agent",
"tools": ["tool-id-1", "tool-id-2"],
"knowledge_sources": ["index-pattern-1"],
"llm_connector_ref": "optional-connector-id"
}
```

## Install ordering

Fleet should install assets in dependency order:
1. Tools (no dependencies)
2. Agents (reference tools)
3. Workflows (may reference agents)

## Prior art

Recent asset type additions to the package ecosystem:
- `alerting_rule_template` (spec 3.5.0)
- `slo_template` (spec 3.5.6)
- `esql_view` (spec 3.6.0)

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

Start by reading the package-spec change proposal and the implementations of recent asset types such as alerting_rule_template, slo_template, and esql_view. Trace how elastic-package build, validation, and test discover and install assets. Done means the three directories are packaged, schemas and dependency ordering are validated, and installation, enabling, triggering, and agent invocation are tested.

Written by the indexing model from the issue text.