feat: add AgentManifest for declarative capability profiles

[ImenGBY]

Summary

Add an optional AgentManifest to the Agent class that formally declares an agent's input requirements, output types, trigger conditions, and tool capabilities. This enables platforms to manage agent lifecycle, resolve dependencies automatically, and compose agents into chains without custom wiring.

Motivation

Today, a Strands agent is defined by its runtime configuration: model, tools, system prompt. There is no way to declare what an agent needs or what it produces without inspecting its code or documentation. This means every multi-agent deployment requires manual dependency tracking, custom wiring between agents, and runtime failures as the only signal that something is missing.

This PR adds a declarative manifest that solves three problems:

1. No dependency declaration: a platform can now check if an agent's inputs are available before running it
2. No composability contract: agents can be chained by matching output events to input events, no custom code
3. No lifecycle management: agents can be registered dormant and activate automatically when dependencies arrive

Changes

• New: src/strands/agent/manifest.py with AgentManifest, InputContract, OutputContract, Trigger dataclasses
• Modified: src/strands/agent/agent.py added optional manifest parameter to Agent.init
• Modified: src/strands/agent/__init__.py exports new classes
• New: tests/strands/agent/test_manifest.py with 24 unit tests (all passing)
• New: rfcs/0001-agent-manifest.md with full design rationale and usage examples

Backward Compatibility

• manifest parameter is optional and defaults to None
• Existing agents without manifests work exactly as before
• No breaking changes to any existing API
• Zero impact on prompt caching (manifest is never sent to the model)

Tests

24 unit tests covering creation, serialization, deserialization, file loading, roundtrip, and dependency satisfaction checking.