feat(events)!: make session id explicit in event stream

[galuszkm]

Description

Give callers explicit control over the session id in the event stream instead of inferring it from manifest ordering. The SESSION_START payload is restructured into a stable envelope so consumers can access both the session id and the manifest topology in a predictable way. close() gains an optional data parameter so end-of-stream metadata can be attached at call time rather than being fixed at wiring time. The redundant "type": "agent" field is removed from AGENT_START and agent-stop payloads since it duplicated information already on the event envelope.

Related Issues

N/A

Type of Change

• Breaking change

YAML / API Impact

Yes — breaking changes to the public Python API and the event stream contract.

• ResolvedConfig.wire_event_queue() now accepts an explicit session_id: str | None = None keyword argument. Previously the session id was derived automatically from the first session manager found in the manifest. Callers that relied on implicit derivation now receive None unless they pass session_id explicitly.
• first_session_id(manifest) has been removed from strands_compose.manifest. Any code importing it will break.
• SESSION_START event data shape changed from the raw SessionManifest.model_dump() dict to {"session_id": <str | null>, "manifest": <SessionManifest dict>}. Consumers reading event.data["agents"] directly must update to event.data["manifest"]["agents"].
• EventQueue.close() now accepts an optional data: dict parameter.
• AGENT_START and AGENT_COMPLETE event payloads no longer include the "type": "agent" field.

Config YAML schema is unchanged.

Testing

How have you tested the change?

• I ran uv run just check (lint + type check)
• I ran uv run just test for overall testing
• I added or updated tests that prove my fix is effective or my feature works
• I verified existing examples in examples/ still work

Checklist

• I have read the CONTRIBUTING document
• I have updated the documentation accordingly
• My changes generate no new warnings
• Any dependent changes have been merged and published