Feature: MultiAPI support

[ren-jentic]

Support multi-API workflow search results (api_references)

Summary

The server-side WorkflowSearchResult is changing to support workflows that span multiple APIs. The single api_name / api_id / api_version fields are being replaced by an api_references: list[APIReferenceSummary] field. This PR updates the Python SDK to handle the new format while maintaining full backward compatibility with the old format.

Motivation

Workflows can reference multiple APIs (e.g., a workflow that reads from Slack and writes to Discord). The previous schema only allowed a single api_name per search result, which couldn't represent this. The new api_references list captures all APIs involved in a workflow.

Changes

python/src/jentic/lib/models.py

• Added APIReferenceSummary model for the new api_references entries
• Added _derive_api_name() helper that extracts a single api_name string from either the legacy top-level field or the new api_references[0] — provides seamless backward compatibility
• Updated SearchResult model:
  • api_name changed from required to default="" so missing values don't break validation
  • Added api_references: list[APIReferenceSummary] | None field
  • set_data validator now uses _derive_api_name() to handle both old and new formats
  • Validator also improved: match_score now checks both distance and match_score keys; workflow summary fallback chain is name → summary → workflow_id

python/src/jentic/lib/agent_runtime/api_hub.py

• search_api_capabilities: uses _derive_api_name() for workflow results, passes through api_references, and now correctly constructs SearchResponse with results/total_count/query fields
• ensure_api_names_in_response / _enrich_entity_with_api_name: simplified to use _derive_api_name() instead of full Pydantic model validation — handles both formats
• Fixed pre-existing bugs: _search_all and _search_workflows referenced non-existent SearchRequest attributes (capability_description → query, max_results → limit, api_names → apis)

New test files (36 tests)

• tests/test_search_result_api_references.py — model-level tests for _derive_api_name, SearchResult with new/legacy/operation formats, SearchResponse with mixed results, APIReferenceSummary
• tests/agent_runtime/test_api_hub_search.py — ensure_api_names_in_response with both formats, search_api_capabilities end-to-end with new/legacy/multi-API workflow results

Backward compatibility

The _derive_api_name() priority chain ensures existing integrations keep working:

1. Top-level api_name string (old format) — used if present and non-empty
2. api_references[0].api_name (new format) — fallback
3. "" — if neither exists

Consumers that only read result.api_name see no change. Consumers that need all APIs can now access result.api_references.

Test plan

• All 36 new tests pass
• All 94 existing tests pass (130 total, zero regressions)
• New-format workflow payloads (api_references, no api_name) validate correctly
• Legacy-format payloads (top-level api_name, no api_references) still work
• Multi-API workflows derive api_name from first reference
• Operations are unaffected

[aberming]

Looks good to me - didn't spot any issues.