🔒 Validate tile overlay URL templates to require HTTP/HTTPS schemes

[esenmx]

🎯 What: Fixed unvalidated URL template in tile overlay that allowed arbitrary URL schemes.
⚠️ Risk: Potential SSRF or local file access if unvalidated URL templates (such as file:// or arbitrary schemes) were passed to tile overlays.
🛡️ Solution: Added URL template scheme validation in Dart toPlatform() and Swift addTileOverlay to enforce http:// or https:// schemes.

---

PR created automatically by Jules for task 6475941354405381996 started by @esenmx

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[esenmx]

Closing: the premise does not hold. urlTemplate is written by the app developer in their own Dart code, not sourced from untrusted input, so there is no trust boundary for SSRF or local-file access to cross; the app already owns its sandbox. More importantly, file:// templates are a documented MapKit feature: Apple's MKTileOverlay.url(forTilePath:) states the default implementation builds the URL from the template you provide and "You can locate the tiles either on a local file system or on a remote server", which is how apps ship offline tile packs, and this package promises MKTileOverlay(urlTemplate:) parity. This change would break that use case for existing consumers while fixing no real vulnerability.

As implemented it also: rejects RFC 3986-valid uppercase schemes via case-sensitive startsWith/hasPrefix; throws inside the controller's _enqueue closure so addTileOverlay rejects with a raw ArgumentError, contradicting the documented "catch MapKitException for any map failure" contract; and duplicates an unreachable Swift guard that yields a different error type for the same condition.

[google-labs-jules]

Closing: the premise does not hold. urlTemplate is written by the app developer in their own Dart code, not sourced from untrusted input, so there is no trust boundary for SSRF or local-file access to cross; the app already owns its sandbox. More importantly, file:// templates are a documented MapKit feature: Apple's MKTileOverlay.url(forTilePath:) states the default implementation builds the URL from the template you provide and "You can locate the tiles either on a local file system or on a remote server", which is how apps ship offline tile packs, and this package promises MKTileOverlay(urlTemplate:) parity. This change would break that use case for existing consumers while fixing no real vulnerability.

As implemented it also: rejects RFC 3986-valid uppercase schemes via case-sensitive startsWith/hasPrefix; throws inside the controller's _enqueue closure so addTileOverlay rejects with a raw ArgumentError, contradicting the documented "catch MapKitException for any map failure" contract; and duplicates an unreachable Swift guard that yields a different error type for the same condition.

Understood. Acknowledging that this task is not applicable as file:// URL templates are a documented MapKit feature for offline tiles and urlTemplate is developer-controlled without a trust boundary crossing. Stopping work on this task.