08abc5eba8
Every PLATFORM_HINTS entry for a messaging platform (Telegram, WhatsApp, Discord, Slack, Signal, WebUI, desktop) teaches the model the MEDIA:/path convention because an interception mechanism actually resolves it there (native attachment delivery, or a validated/inlined data URL). The cli entry, which has no such mechanism, explicitly tells the model NOT to use it and to state the path in plain text instead. The api_server entry had neither instruction. Its /v1/runs handler never routes the final response through any MEDIA: resolver (confirmed against source: none of the four call sites of the api_server module's media-tag resolver are inside its runs-endpoint handler), so a MEDIA:/path tag there renders as inert literal text in the API response — exposing a raw host filesystem path to the caller with no delivery ever taking place. Nothing platform-specific told the model not to use a convention it's correctly taught for several sibling platforms in this same dict, so the general cross-platform habit could surface here too, unlike cli where an explicit prohibition already closes the gap. Mirrors cli's prohibition, adapted for api_server's actual constraint: no "state the path in plain text" fallback, since a typical API caller has no filesystem access to the host at all. Points at "a registered file-delivery tool" generically rather than naming any specific tool, since api_server toolsets are deployment-defined.