Issue Summary

When converting a page from storage format to ADF, Confluence looks up macro metadata by name. For any macro that isn't built in (Forge or Connect, including macros migrated from Data Center), the lookup falls through to the Jira gadget macro metadata provider. If the site has a system Jira application link, that provider fetches every Jira gadget spec (<jira>/rest/gadgets/1.0/g/...xml) before filtering by name. If any spec returns an error (e.g. HTTP 404), the GadgetException is not caught, and the macro is replaced with an unsupported-content node ("Corrupted content - please contact Atlassian Support").

The failed result is then saved in the draft and in the fabric eligibility content properties, so the page stays broken until the draft is reverted or the page is edited.

Observed on an Isolated Cloud site after a Confluence Data Center → Cloud migration.

Steps to Reproduce

1.  Have a Confluence Cloud site with a system Jira application link whose /rest/gadgets/1.0/g/... gadget spec URLs return 404 (e.g. a link migrated from Data Center) in IC
2. Install a Forge app with an app.connect.key matching the DC plugin key, with a macro key equal to the DC macro name (e.g. ui-button).
3. Migrate (or create) a legacy-editor page containing that macro in storage format:

   <p><ac:structured-macro ac:name="ui-button" ac:schema-version="1">...</ac:structured-macro></p>{code}

4. View the page, or open it in the editor.
5. Issue is happening in this Page 
   https://partner-refined.mirage.atlassian-isolated.net/wiki/spaces/HTS/pages/15958045/Children+Card+Macro

Expected Results

The macro to load properly after the page is published just as it is loading in the edit version of the page 

Actual Results

ecosystem.atlassian.net/browse/ECOHELP-167555

Workaround

• Revert the page draft to the published version (or edit and republish). This forces a fresh conversion