Fix: iOS share text formatting for URLs

[wilsonatb]

Summary

• make iOS share URL payload match Android behavior
• send text and URL as a single string separated by \n\n
• avoid duplicated title/message items in the iOS URL-sharing path

Problem

On iOS, UIActivityViewController was receiving separate items for title, text,
and URL. Some targets like WhatsApp concatenate them without preserving the expected
line breaks, causing the URL to appear attached to the last line of the message.

Fix

Build a single shared text block for URL-based sharing:

• text + "\n\n" + url in Share.Url
• message + "\n\n" + filePath in the URL branch of Share.File

This keeps the change minimal and aligns iOS behavior with Android.

[shanerbaner82]

Nice fix — collapsing the separate UIActivityViewController items into a single "text\n\n url" string is the right call, and it's a faithful port of the Android path: Share.Url on Android does exactly shareText = text.isNotEmpty() ? "$text\n\n$url" : url (resources/android/ShareFunctions.kt). This should resolve the WhatsApp / line-break mashing.

One thing to address before merge, though — it doesn't fully reach Android parity:

title is dropped from the Share.Url path. Android also does putExtra(Intent.EXTRA_SUBJECT, title) (ShareFunctions.kt:41), so the title survives as the share subject. This PR sends only [shareText], so on iOS the title argument becomes a no-op — subject-aware targets like Mail lose it. The iOS equivalent of EXTRA_SUBJECT isn't a share item, it's a UIActivityItemSource implementing subjectForActivityType(_:). Restoring the title that way would make this a true parity fix rather than trading one mismatch for another.

Two smaller notes:

• The URL now goes out as a plain String instead of a URL object. That's consistent with Android's text/plain, but on iOS some targets give richer link previews when they receive an actual URL item — worth a quick on-device check across Messages / Mail / WhatsApp to confirm previews still look right.
• In Share.File, the shouldAppendTitle / shouldAppendMessage flags are a clean way to avoid the duplicate-item problem. Minor: the file-not-found fallback sets shouldAppendMessage = false but not shouldAppendTitle — likely intentional, just flagging for a second look.

Direction looks good; the main ask is preserving title as the activity subject so iOS matches Android's EXTRA_SUBJECT behavior.