fix(workflow): report actual agent kind in analyze text output

[Paulo Lacerda (placerda)]

Summary

agentops workflow analyze --format text hardcoded the Agent target row as Foundry prompt agent (\name:version`).regardless of the project's actual target._friendly_foundry_eval_textdiscarded itstext` argument for that check and returned a constant, so hosted-agent / azd-recipe projects were mislabelled as prompt agents.

The markdown renderer emits the computed explanation unmodified and was already correct, so the two output formats contradicted each other.

Fixes #370

Changes

1. _friendly_foundry_eval_text — remove the hardcoded branch (the fix suggested in the issue)

def _friendly_foundry_eval_text(check: str, text: str) -> str:
    if check == "Evaluators":
        return _friendly_evaluator_list(text.split(", "))
    return _soften_text(text)

The text renderer now passes the computed explanation through, matching markdown.

2. _soften_text — cover every target kind, not just foundry_prompt

This addresses the Related note in the issue. _agentops_config_facts emits f"agentops.yaml targets {target.kind}." into a signal detail, which flows through _soften_text. Because only foundry_prompt was mapped, hosted projects leaked the raw token foundry_hosted into user-facing output.

#: Raw target kinds emitted by :func:`classify_agent` mapped to display names.
#: Ordered longest-key-first so no key is a prefix of another when substituted.
_TARGET_KIND_LABELS = (
    ("foundry_prompt", "Foundry prompt agent"),
    ("foundry_hosted", "Foundry hosted agent"),
    ("model_deployment", "model deployment"),
    ("model_direct", "direct model"),
    ("http_json", "HTTP/JSON agent"),
)

Labels are reused verbatim from the existing eval_analysis._friendly_target map rather than invented, so vocabulary stays consistent across the two analyze commands.

Before / after

Hosted-agent project (agentops.yaml with an agent URL + execution: azd, plus an eval.yaml azd recipe):

Before (--format text):

ok   Agent target  Foundry prompt agent (`name:version`).
ok   Target        agentops.yaml targets foundry_hosted.

After (--format text):

ok   Agent target  Found azd eval recipe at `eval.yaml`.
ok   Target        agentops.yaml targets Foundry hosted agent.

Markdown (unchanged in both — this is the correct value the text renderer was throwing away):

| [x] | Agent target | Found azd eval recipe at `eval.yaml`. |

Prompt-agent projects are unaffected: both formats still report Agent target is a Foundry prompt agent (\name:version`).`

Tests

Three regression tests added to tests/unit/test_workflow_analysis.py:

Test	Covers
test_agent_target_text_matches_markdown_for_hosted_agent	The #370 regression — asserts text == markdown and that the hardcoded string is gone
test_agent_target_text_matches_markdown_for_prompt_agent	Guards against regressing the prompt-agent path
test_hosted_agent_kind_is_softened_in_text_signals	The _soften_text leak — asserts raw foundry_hosted never reaches output

Verified failing-first: with the source reverted to HEAD all three fail (3 failed / 14 passed); with the fix applied all pass (17 passed).

Validation

Check	Result
pytest tests/unit/test_workflow_analysis.py	17 passed
pytest tests/ (full suite)	1111 passed, 5 skipped
ruff check src/ tests/ (v0.15.5, matching uv.lock)	All checks passed
mypy src/agentops/services/workflow_analysis.py --ignore-missing-imports	Success, no issues

Notes for reviewers

• Scope: change 2 (_soften_text) goes slightly beyond the issue's literal one-line suggestion. It is justified by the issue's own Related paragraph, fixes a second real user-visible leak, and is covered by its own test. Happy to split it out if preferred.
• Intentionally not changed: the "Foundry prompt agent." fallback in _foundry_eval_rows (the else when official_eval_reasons is empty) is unreachable — selected requires an azd/cloud/official runner, and both branches that assign those runners always populate exactly two reasons. Touching it would add untestable code. Flagging it as latent-but-dead rather than silently editing it.
• eval analyze was checked for the same bug: eval_analysis.py already renders the target correctly via _friendly_target, so no change was needed there.