Support configuring approved redirect domains for ui/open-link

Start by tracing the ui/open-link handling and how the openai/widgetCSP metadata is defined and consumed in the SDK. Confirm the behavior for configured redirect_domains: matching links skip the warning modal and receive a redirectUrl query parameter, while other links retain existing behavior.

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…?