Add archive support, fix #1634

[stitch]

Support archived links from the dashboard and other sources.

For example, loading the report from example.nl from a few weeks ago:

http://localhost:8080/archive/mail/example.nl/2025-05-04/

This change removes a large chunk of data (millions of rows) from the dashboard as no unique ID is needed anymore to visit the correct report. This saves the unique ID every time a report is made. Additionally it is a very convenient feature for some users that use internet.nl for compliance, as they can now retrieve the last report from December with ease (if this feature is promoted).

This solves issue #1634

The sooner this can be placed into batch, the better, as we then can start cleaning up the database and keep things fast and efficient :)

[bwbroersma]

So this creates a new view for old reports: wouldn't it be more logical to redirect to the already existing view?
Otherwise one resource is viewable via an (almost) unbound number of URL's.

Should double check if the indices are in place for commonly tested domains / what the worst case performance is.

[stitch]

I've done so in the code above.

I've changed it so that:
http://localhost:8080/archive/mail/example.nl/2025-05-04/

Redirects to:
http://localhost:8080/mail/example.nl/2/

There are pro's and cons, you decide which one is what :)

• Using the same view (with the ID) is possible at the expense of an additional query. One for the matching ID and one for the report after the redirect. I've minimized the ID-query to only retrieve the ID.
• In a sense it was already using the same view. But using the redirect matches the stable urls with numbers that users are already familiar with. Using the path with an ID prevents the path with a date to start becoming a separately maintained thing.
• The redirect always removes the work of the user in the address bar, which is generally frustrating. Doing this makes the date-endpoint not a first class route. For the intended automated routes this is fine.

The /archive/ path is intentional. As it otherwise the date-input will overlap with any typo-correction in the ID-path. That would become a maintenance hog.

Using a redirect or not can still be changed afterward if the vision changes. So that would not impede adopting either solution.