Boost: preserve trailing slash on LCP cornerstone URLs

[LiamSarsfield]

Fixes HOG-562

Proposed changes

• Cornerstone_Utils::prepare_provider_data() was stripping the trailing slash from cornerstone URLs before sending them to the Boost cloud LCP analyzer. The key field still uses the sanitised (trailing-slash-stripped) form so cloud-side dedup is unchanged, but the url field now passes through unmodified — preserving whatever form get_list() produced (which already applies the site's permalink-structure convention via maybe_trailing_slash_urls).

Does this pull request change what data or activity we track or use?

No.

Testing instructions

1. On a site with a trailing-slash permalink structure (the WordPress default), set a cornerstone page that isn't the home — e.g. /about/.
2. Trigger LCP analysis via the Boost dashboard, or:

   wp eval '(new \Automattic\Jetpack_Boost\Modules\Optimizations\Lcp\LCP_Analyzer())->start();'
   

3. Inspect the URL the plugin sends to the cloud (e.g. via the local Hydra logs in a dev environment). The cornerstone's url should now end with / (e.g. https://example.com/about/), matching the canonical form WordPress would otherwise 301 to.

Before this change the URL was sent without the trailing slash (https://example.com/about). Sites whose edge treats the two forms differently — security plugins, WAFs, or hosting-level rules — could respond with redirects or 403s to the no-slash form, causing LCP analysis to fail on otherwise-valid cornerstone pages.

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

---

Boost plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[jp-launch-control]

Code Coverage Summary

This PR did not change code coverage!

That could be good or bad, depending on the situation. Everything covered before, and still is? Great! Nothing was covered before? Not so great. 🤷

Full summary · PHP report · JS report

[LiamSarsfield]

sanitize_url() here is just untrailingslashit() - no escaping or validation. key still goes through it for dedup, so only the outbound url form changes.