[Feature Request] Persistent user fixes, in any form.

Prerequisites

• I searched for any existing report about this feature request to avoid opening a duplicate.

Is this feature request related to a problem?

Yes

Feature Request Description

I always thought of Dark Reader as the uBlock Origin of dark mode extensions. User friendly, but also appealing to power users with its advanced features.

Only realized it the other day, I was partly wrong as one of the most obvious (to me at least) feature is missing, user control over page rules.

While this can be done in DevTools, it is not persistent and gets reverted at the next browser restart. Even though the disavantages of a system like this was pointed out to me in a discussion, I think user error is always a risk with any application/extension, and the benefits of this would outweigh the possibility of such errors.

A few solutions to this came to mind for persistent user rules, some easier, some harder to implement.

1. Just make it persistent over session, even if they get reverted on an extension update.

Pros (+): User control over their browsing experience, which is one of the key features of this extension. Custom colors (which can't be done through pull requests), personal use cases (canvas of google spreadsheets shouldn't be inverted if images are used as images get inverted too), etc.
Cons (-): Some might complain that it got reverted, but it can be solved by the user by exporting their fixes, can block extension updates through Firefox (unlike in Chrome), etc.

2. Also persistent, but even through updates, the modified rules shouldn't get updated at all. However, mark them in bold or in a different color, or sort them to the top of the list to be clearly visible for the user that they modified it.

Pros (+): Same as above.
Cons (-): Users might report issues that are due to their modification, but can add another checkbox here before reporting a bug.

3. Make a separate empty fix list, where users can add their own. Also make it persistent over updates. If the new rule's domain is the same as an existing one, user-added fixes should get priority. (best approach in my opinion)

Pros (+): Same as above, but solves the issue of fix updates, as the original ones could be constantly updated freely.
Cons (-): Since user error can never be fully avoided, I don't see any other cons to this.

4. Versioning system for fixes. Each fix should get a version number. If a rule was modified prompt the user to update it, or ignore the this fix version, until a new one gets released. Optionally, can even do checks for modified ones, and compare to original, and only update the parts that wasn't modified by the user (if a rule line was deleted, don't add it back, if a color was changed, don't modify, etc.).

Pros (+): All the above, but much more organized and due to prompts it's clear for the user what's happening, lowering, chances of error.
Cons (-): Cost to implement.

Screenshots

No response

Additional Context

I found a similar open FR, but it's not exactly the same and no suggestions were given.

Non vengono indicati file, test o punti di ingresso. Inizia individuando il comportamento esistente di page-fix e della persistenza, quindi esamina la richiesta di funzionalità aperta simile citata nell’issue; prima che l’implementazione possa essere considerata completata, è necessario aver preso una decisione definitiva tra gli approcci proposti per la persistenza e il versionamento.