Fix wrapping of inline code in rendered markdown

What does this MR do and why?

Followup to !201484 (merged) to address behavior for really long inline code snippets.

References

Screenshots or screen recordings

Before After
Screenshot_2025-08-15_at_14.13.41 Screenshot_2025-08-15_at_14.13.07

How to set up and validate locally

Create an issue or MR in the GDK that has the following description:


This quote has really long inline code:

>>>
FYI, this change has been causing some verification failures in Geo. The pages deployment file was synced to the Geo secondary site, but the `resource_exists?` check was returning false, despite the file existing on the secondary S3.

We did further investigation and discovered that the stored file path on S3 from the `/pages_deployments/` dir onwards is `/pages_deployments/22109/6dd76dd7cb5359f54edb9eb0becd33d19118d3e93e266ef7644cf7b9ad2b9ed1262dfinalb90bfa2df272bd6dee9b05ba3d0b74d1b33f0ffc7a0fc43f2bf4338bb5bf6d0d20250612-47656-ezv00n` but the method above was checking for `/pages_deployments/22109/d0b74d1b33f0ffc7a0fc43f2bf4338bb5bf6d0d20250612-47656-ezv00n` that's why it returns false and the verification fails.
>>>

I was under the impression that the filename would be trimmed upon creation of a deployment.

I'm wondering:

1. For new deployments, does the Geo check work fine because the stored filename is the same as the trimmed one?
2. For old deployments, does the Geo check fail because of this disparity?

You will see that when you save it, the really long inline code breaks and wraps appropriately.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #561290 (closed)

Merge request reports

Loading