Archiving old documentation releases

As discussed internally in team meeting, we are observing many repos reaching the size limit in their ``gh-pages`` branches - as a consequence of their increasing number of releases and no-cleanup default policy for old releases. While this is fine, it does surface some problems:

- Old documentation releases might have to be archived and pushed to a separate location to avoid bloating the ``gh-pages`` branch. This will also have a positive effect for the ``gh-pages`` deployment since it will reduce their size
- Determining how many releases are kept on gh-pages should be an optimization problem between two variables: the number of releases desired by the maintainers, and the actual size limit of ``gh-pages``.

The problem is two-fold.. both aspects will have to be handled. Adding this logic as part of our ``doc-deploy-stable`` action might make the most sense... although the implementation for each of these elements could be done in separate sub-actions directly, which could then be used in standalone format.

Dropping my thoughts below...

---

## Archival of old releases

Documentation for old releases take up space. And as we move forward in time, they might stop being used by end-users. Which make their immediate availability (i.e. deployed HTML) not necessary.. if a user is asking for documentation regarding version 0.35 of PyMAPDL when we are already in 0.73, that is fine, but the user cannot expect to find that documentation immediately available. Similarly to what is done in libraries and other places, we should have an archive for old releases. The entire HTML docs should be zipped and shipped to this archive location where users will be able to retrieve them from (by downloading them). This is seen in other places like the NumPy or SciPy docs. Main implementation points (to be discussed):

- In a similar fashion to the ``ansys/example-data`` repository, we could have an ``ansys/docs-archive`` repository where projects can dump their old documentation releases:
- The main benefit in this approach is alleviating the size of the repository... ``gh-pages`` are already single-push, orphan pages typically, so the history is not preserved. Old docs removed won't take up space. If we decided to keep the old release documentation zip files within the same repo, the size of our repos would explode... and cloning would be painful unless done in optimized manners. By pushing the artifacts to an already-expected, heavy repo we limit this issue
- Instead of having all artifacts on the main branch... we could follow a different approach! Orphan branches per repository:
- This would allow repos to own their space and avoid issues with other repos pushing at the same time to the same branch
- The name of the branches should be exactly the same as the name of the repo + a prefix if we agree to it. For example, for the ``ansys/actions`` repository it would be ``docs-archive/ansys/actions``. No ambiguity issues since the name is determined automatically.
- This would also allow us to control the ``main`` branch of that repo, where we could include documentation in the form of a README, and cleanup workflows or validation workflows etc.
- The zipping of old docs, push to shared location, and removal of content from the ``gh-pages`` branch should all be done from the same action.
- The zip files should be pushed to ``git-lfs`` rather than a simple push to the branch. We don't know the size of the artifacts we will be pushing there.. but we will now they are heavy for sure. By leveraging ``git-lfs`` simple cloning of the repostory can be lightweight.

## Determining how many releases are kept in ``gh-pages``

This is a feature that we might want to expose to maintainers to control. We can enable sensible defaults of course. However, at the end of the day, the physical limitations from ``gh-pages`` are the ones that take precedence and we should try to handle it for our libraries. Main implementation points:

- Maintainers should be able to control how many releases they want to keep in their ``gh-pages`` branch:
- However, we should clarify that this number will be on a best-effort basis and that the ``gh-pages`` branch limitations will take precedence.
- Determining physical space and how many branches should be kept has to be implemented as an algorithmic, reproducible system:
- Off the top of my head I am thinking on the following... if we measure the available doc folders and the size on``gh-pages`` the following must be ensured:
- Stable docs should only take for ``gh-pages-max-size - (last-release-size * 1.15)``: this will make projects have at least some buffer space from release N to N+1 in case it increases largely in size.
- The above percentage (i.e. 15%) is opinionated and debatable 😄
- The physical size takes precedence over the number requested by the maintainer: if the maintainer's number is compatible with the previous algorithm, then great; if not, we start removing old releases until the size limit algorithm is "green"
- Versions.json adaptation, information note etc. should be adapted by us as part of the action
- We can easily inject a statement to the ``CNAME/version/index.html`` page as an admonition where we explain what to do for old releases. We can even adapt the links that show up so that they point to the specific artifacts!
- The "Older version" entry in the dropdown might not even need to be adapted since it already points to ``CNAME/version/index.html``
- Whether this needs to be implemented as a separate action or in combination with the previous action is something I am completely open to. No strong feelings on my side.

## Integration into ``ansys/actions/doc-deploy-*`` actions

I've got my doubts here to be honest... I think the ``ansys/actions/doc-deploy-stable`` is the best location, but maybe we want to add this to a different action as well (?)... or just keep it independent and have teams add it to their workflows (?)

Start with the ansys/actions/doc-deploy-stable and related doc-deploy-* actions to understand their current release deployment flow. Review how versions.json and CNAME/version/index.html are handled, then clarify the archive location, retention algorithm, and action boundaries with maintainers. Done should include agreed behavior for archiving old releases, enforcing size limits, and updating links or notices.

Written by the indexing model from the issue text.