Expose candidate browsing metadata for signal authoring

[bokelley]

Context

Interchange is building an MCPUI for ESA signal management that needs to stay adapter-agnostic while matching the existing salesagent admin signal workflow. The current Tenant Management API gives us signals/adapter-capabilities and signals/candidates, which is enough for simple candidate-backed creation, but not enough for a generic browser/drill-down UI.

Today, mapping_kinds[] exposes directly mappable kinds, while signals/candidates also supports browse-only candidate types such as GAM custom_targeting_key and SpringServe key. A generic client has to know adapter-specific browse steps to discover parent keys before fetching child values/lists.

Request

Extend GET /api/v1/tenant-management/tenants/{tenant_id}/signals/adapter-capabilities with candidate browsing metadata, for example:

• supported candidate types for this adapter
• which candidate types are browse-only vs directly mappable
• parent/child relationships between candidate types
• preferred default candidate type
• whether each type supports search, pagination, and parent filters

Why

This lets embedded clients build signal authoring UIs without hard-coding GAM/SpringServe/FreeWheel-specific candidate traversal. It also keeps default_signal and adapter_config_template as the contract for actual mapping creation while making discovery fully machine-readable.

Current workaround

Interchange can hard-code the known browse-only types for the parity implementation, but that does not scale to new adapters or future candidate kinds.