Issue Summary

LMS fails to discover and fix legacy Confluence attachment and server URLs stored inside <ac:parameter> macro parameters

Steps to Reproduce

1. In Confluence Server / Data Center, create or import pages containing macros where <ac:parameter> elements hold Server base URLs or attachment/thumbnail URLs (e.g., inside jira, toc, code, drawio, tip, info, details, or expand macros).
2. Migrate the spaces to Confluence Cloud using CCMA / JCMA.
3. Run the Link Migration Service (LMS) job to remap legacy Server URLs to Cloud.
4. Inspect the migrated page storage format (bodycontent.body) or observe the macro rendering in Cloud.

Expected Results

• LMS discovers all legacy Server URLs embedded within <ac:parameter> elements across structured macros.
• All matching URLs (such as /download/attachments/<contentId>/... or Server base URL endpoints) are remapped to the destination Cloud URL and corresponding Cloud entity IDs.

Actual Results

• LMS completely ignores URLs residing inside <ac:parameter> elements.
• The legacy Server URLs remain untouched in bodycontent.body.
• LMS does not flag these as FAILED or SKIPPED in job execution metrics because the scanner never extracts or queues macro parameters for transformation.
• Affected macros fail to render correctly, attempt to fetch from unreachable on-prem server endpoints, or display broken resource links.

Root Cause Details:

1. Extraction / Discovery Gap: Confluence's storage engine does not index text inside <ac:parameter> into the relational LINKS table during import/save. 
2. Transformer Gap: LMS XHTML/ADF transformers only evaluate anchor tags (<a href="...">) and do not traverse the DOM tree for <ac:parameter> inner text.

Storage Format Example:
 <ac:structured-macro ac:name="jira">    <ac:parameter ac:name="server">https://<confluence-server-url>/download/attachments/XXXXXXXXX/...</ac:parameter></ac:structured-macro>

Workaround

Contact Atlassian Support to see if options are available.