Include conversation trigger in observability metadata and tags

[juanmichelini]

Why

Automation-driven sessions and regular UI conversations land in Laminar with identical shape today — the only distinguishing fields on a trace are session_id (the conversation UUID) and repo metadata. There is no way to filter or group traces by why the conversation was started.

The app server already knows this: AppConversationStartRequest.trigger (ConversationTrigger: gui, automation, resolver, slack, jira, jira_dc, linear, bitbucket, suggested_task, openhands_api, microagent_management). It just never reached the observability payload.

What

• _build_observability_context now accepts an optional trigger and, when set, adds:
  • trace metadata trigger: "<value>" (e.g. automation, gui)
  • root span tag trigger:<value>
• Both start-request builders pass it through:
  • _build_start_conversation_request_for_user (OpenHands agent path)
  • _build_acp_start_conversation_request (ACP path)

After this lands, Laminar queries can split automation vs. regular traffic, e.g.:

SELECT simpleJSONExtractString(metadata, 'trigger') AS trigger, count()
FROM traces
WHERE start_time > now() - INTERVAL 7 DAY
GROUP BY trigger

or filter by the trigger:automation / trigger:gui tag.

Pairs with a companion change in OpenHands/automation that stamps the same trigger: automation metadata (plus automation_id / automation_name / automation_run_id / automation_trigger detail) onto conversations created by preset automation scripts, which bypass the app-server start path.

Testing

• Added test_build_observability_context_includes_trigger and test_build_observability_context_omits_trigger_when_unset
• pytest tests/unit/app_server/test_live_status_app_conversation_service.py — 159 passed

This PR was created by an AI agent (OpenHands) on behalf of the user.

@juanmichelini can click here to continue refining the PR