Add Input Validation

[theelderemo]

Implement URL validation in the scope manager before adding domains to prevent malformed URLs from breaking project databases.

[enlguy]

@theelderemo I'd be happy to contribute to this project, and already have an idea of how to implement the validation you mention in the ScopeManager file. You may assign this to me.

[theelderemo]

Of course have it it! I welcome all contributions:)

[enlguy]

@theelderemo
I’ve got the URL validation working in the Scope Manager to stop malformed URLs from entering the database. Before opening the PR, I just want to confirm a few details to make sure the behavior matches your expectations:

It rejects malformed/incomplete URLs (like example.com or http:/bad-url) instead of trying to fix them.
It normalizes hostnames to lowercase, removes default ports (:80, :443), and strips trailing slashes and # fragments to avoid duplicates.

Questions:
Should bare domains like example.com be auto-prefixed with https://, or kept invalid?
Should #section fragments ever be preserved (e.g. for SPAs), or always removed?

Everything seems solid in testing — just want to align on these details before I push the PR.

[theelderemo]

Let's auto-prefix with https:// when a user provides a bare domain for a scope rule or the primary project target. This matches the existing behavior in ProjectStartup.js and is more user friendly than rejecting it, but if a bare domain is somehow discovered during crawling/analysis (which should be rare), we should probably treat it as invalid or ambiguous rather than assuming a scheme.

And let's stick with always stripping fragments. Fragments are client side only and not sent to the server. Stripping them prevents duplicate entries for the same server resource in our site map and simplifies scope matching. While SPAs use fragments, our primary focus is server side testing for now, and tools like web_request won't use the fragment anyway. We can revisit this if deep SPA/client-side analysis becomes a bigger focus later.

Unless you think otherwise. This is a community project, and it belongs to all of us. You can pitch ideas, change logic if one way works better than the other way.

But the other normalization steps (lowercase hostname, remove default ports, strip trailing slash) are definitely good practices and should remain.