Add interstitial redirects and old images.

[freakboy3742]

In the process of writing #599, I noticed that the image link on the top of the Briefcase release page on PyPI was broken.

This was caused by the recent website refactor, and was corrected in main as part of beeware/briefcase#2172, but I hadn't considered all the historical image links that would have been affected.

This PR restores the images for all "active" projects to their original locations, so that historical image links will continue to work. Unfortunately, it doesn't look like Lektor will let us to redirects for images.

However, it turns out the redirects for old URLs weren't working either - although the old Briefcase URL has a redirect defined, it's parent page doesn't have any content, and as a result, what should have been a redirect is currently returning a 404.

This PR adds content pages all the "interstitial" URLs in the project hierarchy - to specific new locations where possible; to /project where there isn't an obvious mapping.

This then allows the images to be served at their original locations, and the old project URLs to be redirects.

[github-actions]

Visit the preview URL for this PR (updated for commit 565c18c):

https://beeware-org--pr600-redirect-fix-fd2p944z.web.app

_{(expires Fri, 07 Mar 2025 14:03:46 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: b0da44bc067e7d9a4255c77cb2c5fce572218cec}

[mhsmith]

This PR restores the images for all "active" projects to their original locations, so that historical image links will continue to work.

Doesn't this mean there are now two copies of each image? This will inevitably cause confusion when someone updates one and doesn't update the other. It would be better to either:

• Update all the incoming links – unlike links to pages, we can reasonably assume that nothing outside of our control has ever linked directly to an image; or
• Remove the new image URLs and make everything use the old ones.

[freakboy3742]

This PR restores the images for all "active" projects to their original locations, so that historical image links will continue to work.

Doesn't this mean there are now two copies of each image?

Yes, it does.

This will inevitably cause confusion when someone updates one and doesn't update the other.

I agree it's a PITA that we need a copy and can't just use a symlink. If I had to retroactively explain it, I'd argue it's a way to capture what was the logo as of March 1 2025... that's not a great explanation, but it's an explanation.

It would be better to either:

• Update all the incoming links – unlike links to pages, we can reasonably assume that nothing outside of our control has ever linked directly to an image; or
• Remove the new image URLs and make everything use the old ones.

To the best of my knowledge, we have updated all the existing links - but there's still some we can't update.

1. We can't update the README for a published PyPI entry, and those pages include a link the old location - e.g., https://pypi.org/project/briefcase/0.3.22/
2. There are third-party links that we can't control. Cool URIs don't change, and yanking the old image is "uncool" 😎 .

Admittedly, I'm not overly concerned about (2). (1) isn't a huge issue either... but it's also a relatively trivial fix for the cost of a couple of copied files on disk. I'd argue it's worth the inconvenience, but I also won't push back too hard if you think we should drop them and just let the images go stale.

[mhsmith]

We can't update the README for a published PyPI entry, and those pages include a link the old location

OK, we'd better not break those. In that case, if the entire projects directory is now only for backward compatibility, can you add a README or something explaining what its purposes are, and why the images can't be a redirect?

[freakboy3742]

@mhsmith I've added an explainer README.