draft: add userscript @require loading

[AlexTzib]

Hi @Manuito83, opening this one as a draft because @require support changes how third-party code is loaded and injected. I would like your opinion before treating it as ready.

This is a conservative first pass from the older DX/userscript compatibility work in #289. Instead of fetching dependencies during every page load, it resolves @require URLs when a script is added or updated, stores the fetched dependency source with the userscript model, and prepends those dependencies before the main script during injection.

What changed:

• stores fetched @require sources alongside the parsed @require URLs
• resolves @require dependencies for remote scripts during fetch/load
• resolves @require dependencies for manually pasted scripts before saving
• injects cached required sources before the userscript source
• preserves cached required sources through JSON backup/restore
• adds small tests for source ordering and serialization

Questions before this should be considered mergeable:

• Is caching dependency source in the userscript model acceptable, or would you prefer resolving on every update/check only?
• Should @require be limited to HTTPS only? I currently allow both http and https, but I can restrict it if you prefer.
• If one dependency fails to load, should the app reject the save as it does here, or save the script but disable it / warn only?

I kept this separate from the safer grant-warning/docs/test PRs because the review surface and risk are higher.

[AlexTzib]

Hi @Manuito83, I re-reviewed this draft and I think keeping it draft is the right call for now.

The approach is conservative in one good way: it fetches @require dependencies when the script is saved/updated, then injects the cached source before the main script, so page loads do not need network calls.

The main policy questions I see before this should be marked ready are:

• Should @require be HTTPS-only? The current draft allows both http and https, but HTTPS-only is safer for third-party script dependencies.
• Should there be a timeout / size limit / content-type guard when fetching dependencies? Right now a slow or very large response could make saving feel stuck or store a lot of code in the userscript backup payload.
• If one dependency fails to load, should the app reject saving the script as this draft does, or save it disabled / warn only?

I do not think these are CI issues. They are more about the security and UX policy we want for third-party dependency loading.

[Manuito83]

I can't say. This would have to be @Kwack-Kwack