Support configuring approved redirect domains for ui/open-link

Comienza rastreando el manejo de ui/open-link y cómo se definen y consumen los metadatos openai/widgetCSP en el SDK. Confirma el comportamiento para redirect_domains configurados: los enlaces coincidentes omiten el modal de advertencia y reciben un parámetro de consulta redirectUrl, mientras que los demás enlaces mantienen el comportamiento existente.

Is your feature request related to a problem? Please describe.

Upon ui/open-link, ChatGPT shows a warning modal to the user, confirming that they intended to visit said page:

However, the modal can be unnecessary (and annoying for users) if the app developer has genuine reasons to redirect/open a link that they control.

Secondarily, some apps have use cases where they want to ui/open-link a separate page for e.g. checkout and then redirect the user back to the conversation where they started.

Describe the solution you'd like

In the ChatGPT Apps SDK, we introduced ["openai/widgetCSP"].redirect_domains, an array of domains:

        _meta: {
          "openai/widgetCSP": {
            connect_domains: [],
            resource_domains: [],
            redirect_domains: ["https://*.company.com"],
          },

ui/open-link to any of these domains a/ won't trigger the safe link modal and b/ we attach a ?redirectUrl query param to the outgoing URL so that the destination can redirect the user back to where they came from at the end of their flow. (e.g. checkout)

Describe alternatives you've considered

Alternatives names I considered instead of redirect_domains:

• safe_domains: while technically the modal is called the "safe link modal" (or something like that) and this disables that modal, just because a domain is in this config option doesn't mean it's safe. I also feel like this is too close to seem related to the "content security (safe) policy" even though it doesn't directly affect CSP.
• return_to_chat_domains: more obvious, but so verbose and specific about the redirectUrl query param. Doesn't go as nicely with connect_domains and resource_domains.
• interstitial_flow_domains: more focused on the purpose that the domains are used for, but kind of an awkward word. just flow_domains isn't enough. maybe just interstitial_domains…?