[6.x] Encode asset URLs

[duncanmcclean]

This pull request fixes an issue where asset URLs weren't encoded, so filenames containing spaces or accented characters produced invalid URLs.

This was happening because Asset::url() and Asset::absoluteUrl() assembled the URL from the raw path, leaving characters like ú and spaces untouched. An asset called Dún Laoghaire_18 2.jpg came back as https://ams3.digitaloceanspaces.com/mywebsite/Dún Laoghaire_18 2.jpg, which Str::isUrl() doesn't consider a URL. Browsers percent-encode a raw src attribute for you, so images still rendered — the breakage only showed up server-side, where passing the URL into something like the Glide tag would send it down the wrong branch.

This PR fixes it by encoding each path segment with rawurlencode() when assembling both URLs, and decoding the path in AssetRepository::findByUrl() so encoded URLs resolve back to their asset. Since encoding and decoding are exact inverses, filenames containing literal percent sequences round trip correctly too — a file named photo%20one.jpg gets the URL photo%2520one.jpg. That does mean any old unencoded URLs to such files stored in content will no longer resolve via findByUrl(), which is inherent to encoding the URLs at all.

Fixes #5593

[jasonvarga]

URL::encode() (src/Facades/Endpoint/URL.php:326-346) was built for encoding a URL that may already be partially percent-encoded — it rawurlencode()s and then maps a set of sequences (%2F, %40, %3A, ... %25→%) back to their literal characters so it doesn't double-encode an already-encoded URL. Reusing it here on a raw filesystem path (Asset.php's url()/absoluteUrl()) breaks that assumption: if a filename already contains a literal %XX-looking substring, it gets treated as "already encoded" and passes through untouched.

Repro: an asset with the literal filename photo%20one.jpg:

• Asset::url() encodes it to .../photo%20one.jpg — unchanged, since the existing %20 is preserved as if it were already an encoded space.
• AssetRepository::findByUrl()'s new rawurldecode() then turns that into photo one.jpg, which doesn't match the actual stored path photo%20one.jpg. The asset becomes unresolvable via the url() → findByUrl() round trip.

This is narrow (filenames containing literal percent-encoded-looking sequences), but it's a real regression — these assets resolved fine before this change since neither side encoded/decoded. None of the added test cases (nothing to encode, spaces, accents, spaces in folders) cover a literal %XX substring, so it's not caught by CI.

Needs fixing before merge: don't reuse URL::encode() (designed for full URLs) on raw asset paths. A plain per-segment rawurlencode() — without the "preserve already-encoded" table — would round-trip correctly through rawurldecode() for all inputs, since it never assumes the raw path is pre-encoded.