chore(deploy): Decide the support policy for the frozen legacy RAG pipeline images

[joelbarmettlerUZH]

The legacy default_rag_pipeline and shared_rag_pipeline are frozen: their code is deleted and the compose files pin their last published images (v0.319.0) in the nightly and latest stages so existing corpora keep ingesting. A published image cannot receive a fix, and main no longer contains the code that built it — so today there is no mechanism at all for shipping a legacy bug fix, and no statement of how long those images are supported.

"The images stay published" answers keep running as-is, which is necessary but not sufficient. A customer hitting a legacy bug currently has one option: migrate the corpus into a new self-service knowledge database. That may well be the right answer, but it should be a stated policy rather than the absence of one.

The standard shape is a maintenance branch, not a fork: cut release/0.319 from the last tag that contained the legacy code, backport fixes there, and publish v0.319.x patch releases (PyPI dists plus rebuilt legacy image tags). Customers on legacy pin to that line. Core is never forked.

In scope

• Decide and write down whether legacy fixes are shipped at all, and until when.
• If they are: cut and document the maintenance branch, its release process, and which image tags it publishes.
• If they are not: state the EOL date and the migration path customers are expected to take instead.
• Publish whichever answer where customers will see it — the deployment guide, not only an ADR.

Out of scope

• Reinstating the legacy code on main. That decision is made, in 2026_08_31_legacy_rag_pipelines_frozen_and_removed.
• Building a data migration from a legacy corpus to a self-service database. That is a separate piece of work, and needs the embedding-contract question in feat(rag): Per-database processing recipe with an immutable embedding model #1811 answered first.

Accepted when

• A customer running a legacy pipeline can find out, from the docs, whether a fix is possible and until when they are supported.
• If fixes are supported, a maintenance branch exists and the process for publishing a patch from it is documented.
• The freeze ADR's open trade-off ("shipping a legacy fix would mean cutting a maintenance branch — a policy that must exist before it is needed") is resolved and the ADR updated to point at the answer.