Strange behavior if crystal: URLs used in HTML documents or New Root URL Dialog

[davidfstr]

Priority: Low

• There's no legitimate reason for a user to attempt to create a root URL with a crystal: URL.
• Similarly, there's no legitimate reason for an HTML page to link to a crystal: URL.
• Therefore the weird behavior that would result from those events is unlikely to happen in practice.

crystal: URLs in the wild - Hangnails
2026-01-21 

[ ] Implement the following logic

* I. Attempt to create “crystal:” URL from UI should fail with dialog saying those URLs are internal

* II. Downloaded HTML that contains a “crystal:” URL link…
  * A. Consider forcing such links to be preserved by adding the external link prefix. 
    * Pro: Continues to use crystal: prefix for "special" URLs
    * Pro: The "external URL" rewriting behavior is actually desired
  * B. Consider adding "invalid:" scheme prefix
    * Con: Introduces another special URL format.
  * 1. Maybe should be done at top of Resource constructor 👈 
    * Pro: Maintains the abstraction that any URL derived from an original
      HTML document can be passed in safely
    * Con: Q: What if a caller wants to directly create a special URL like an external URL?
      * A: A special factory method inside Resource should be used for this purpose. 
  * 2. Maybe should be done as first normalization step
    * Con: But this implies that original URL starting with crystal: would
      still be listed as first alternative when it probably should not
      be considered a valid alternative at all...
  * 3. Maybe should be done in CALLER of Resource constructor
    * Con: Forces all callers to know about and handle the crystal:
      prefix case themselves, likely in an ad-hoc fashion

[ ] Implement the following existing stub, to cover the (I) case above:
- test_when_try_to_save_new_root_url_that_looks_like_formatted_external_url_or_uses_crystal_scheme_then_shows_error_dialog

[ ] Add test(s) to cover the (II) case above