Add version selector to Docs

[AdrianDAlessandro]

Description

This PR extends on #1355 by adding a version selector widget to the bottom right of the docs (inspired by the Django docs and the MUSE1 documentation).

The widget is built by adding HTML and CSS components to the theme/header.hbs with some JS to dynamically determine which version of the docs we are currently in (just like the banner in #1355, this was LLM-assisted). But the list of versions needs to be generated dynamically, so this is achieved following the same pattern pre-existing in the documentation:

1. Define a jinja template for the header file
2. Write a script to turn that script into the required file
3. Make git ignore the generated file
4. Include a header option in the justfile to run the script

I also have removed the "Other versions of documentation" section of the docs. I believe this widget supersedes the need for that section, which was already a little buggy/confusing because it would always redirect to the development version of the docs.

Screenshots:

An extension on #1188

Close #1188

Assisted-by: Claude Sonnet 4.6

Type of change

• Bug fix (non-breaking change to fix an issue)
• New feature (non-breaking change to add functionality)
• Refactoring (non-breaking, non-functional change to improve maintainability)
• Optimization (non-breaking change to speed up the code)
• Breaking change (whatever its nature)
• Documentation (improve or add documentation)

Key checklist

• All tests pass: $ cargo test
• The documentation builds and looks OK: $ cargo doc
• Update release notes for the latest release if this PR adds a new feature or fixes a bug
  present in the previous release

Further checks

• Code is commented, particularly in hard-to-understand areas
• Tests added that prove fix is effective or that feature works

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.75%. Comparing base (3cb68ed) to head (33466f6).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1356   +/-   ##
=======================================
  Coverage   89.75%   89.75%           
=======================================
  Files          58       58           
  Lines        8529     8529           
  Branches     8529     8529           
=======================================
  Hits         7655     7655           
  Misses        561      561           
  Partials      313      313           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[alexdewar]

This looks great and I'm all for this approach. I suggest we merge this branch directly into main and close #1355.

I do think it would be better if we could avoid displaying the warning on the v2.1.0 page though, as it's a little confusing. I've made a suggestion -- let me know if you think it's workable.

[alexdewar]

Instead of having a separate stable/ folder, I'm wondering if we can figure out which is the stable version on the frontend.

For example, maybe you could change the objects in versions to have separate label and path fields. After this jinja business, you could append (stable) to the label of the first release. We could not show the banner for anything with a label that contains stable. What do you think?

[AdrianDAlessandro]

Ok, I have done similar to this. I have made the objects include an additional stable field that is a boolean that is determined in the generate_header.py python script. With the most recent release being the only one labelled as stable.

This has resulted in not needing to build the separate stable/ folder and also being able to label the stable version as such and not include the banner.

So, currently we'll only see a banner for version 2.0.0 and the development version.

[AdrianDAlessandro]

This looks great and I'm all for this approach. I suggest we merge this branch directly into main and close #1355.

I closed the other PR and deleted the branch and it automatically closed this PR. Silly unexpected behaviour.

I do think it would be better if we could avoid displaying the warning on the v2.1.0 page though, as it's a little confusing. I've made a suggestion -- let me know if you think it's workable.

Yea, I think there is something workable there. Will try it out