Decide how the content middleware should scope the `?version` query parameter (introduced by #120)

[mliebischer]

Context

#120 (History route) introduces ?version=N handling: the fetchPloneContent middleware (apps/aurora/app/middleware.server.ts) passes the query parameter to getContent so that History's "View this revision" can render an old revision. Before that PR the middleware ignored the parameter entirely, so this question is new with #120 — it does not exist in current main.

Because the middleware is the single central content-fetch point, the parameter currently applies to every route. Side effect: a hand-crafted /@@edit/<path>?version=N URL loads the old revision into the edit form, and saving would overwrite the current content with stale data. (Verified live on the branch: with two revisions "v1" → "v2", /@@edit/<page>?version=0 renders the v1 title in the edit form.)

This issue exists so the behavior gets a deliberate team decision instead of shipping implicitly — nothing is decided yet.

How Volto handles it

Volto has no central content fetch — every container dispatches its own getContent(url, version) action, and ?version is opt-in per container. Only the public View.jsx parses the query parameter and passes it along; Edit.jsx never does, so the same URL in Volto silently ignores the parameter.

Options to discuss

1. Pathname guard: only read ?version when no pathname segment starts with @ (CMSUI routes are mounted under @-prefixed segments like /@@edit/..., and Plone reserves @ for views/services, so content ids can never start with it). Small and matches Volto's effective behavior, but implicit. This option was prototyped during Add History route (#30) #120 (middleware change + unit test, A/B-verified live) and pulled out again pending this discussion — the patch can be revived if the team picks this direction.
2. Explicit per-route opt-in: routes declare that they support ?version (e.g. via a route handle or router context), and the middleware only honors the parameter for those routes. More plumbing, but the contract is visible where the route is defined.
3. Keep it global: accept the side effect (the backend still enforces permissions on @history) and document it. Cheapest, but /@@edit?version=N editing stale data is a real footgun.
4. Don't touch the middleware at all — fetch the revision in the public content route loader: the client already ships a dedicated getHistoryVersion (packages/client/src/restapi/history/get_version.ts), and packages/publicui/routes/content.tsx is a thin loader over the middleware context. On ?version=N that loader could fetch the revision explicitly and hand it to the SlotRenderer, while the middleware keeps loading the current content as always. The parameter then has exactly one consumer, /@@edit?version=N cannot exist by construction, and navigation/breadcrumbs/toolbar keep reflecting the current state (arguably more correct than today, where the whole context object is the old revision). Costs: one extra backend request on version URLs, loader-side error handling for anonymous/missing versions, and getHistoryVersion currently returns RequestResponse<unknown> (typing should be improved along the way). If this direction is chosen, the middleware ?version pass-through introduced in Add History route (#30) #120 would be reverted in favor of the loader fetch.

References

• apps/aurora/app/middleware.server.ts (fetchPloneContent)
• [CMSUI] - History route #30 / Add History route (#30) #120 (History route, where ?version support is introduced; listed there as a known limitation)
• Volto: components/theme/View/View.jsx (parses ?version), components/manage/Edit/Edit.jsx (does not)