feat(ui): make collections and workflow views responsive

[delucis]

Summary

This PR continues the work of #7820 and #7825 by tackling part of the CMS UI and making it responsive. Some of the design decisions were inspired by #7298.

This PR combines the collections view and the editorial workflow view because they share a common container element, which has its minimum width removed.

• Collections and workflow views both now adapt down to ~230px wide (with English UI strings) and use a smaller page margin on small viewports.
• On small screens, the collections sidebar is displayed above the list of entries (as first shown in feat(ui): add responsive styling for mobile compatibility #7298).
• Where necessary, some layouts can now reflow (e.g. “new post” buttons on top cards and view controls for sorting, grouping, etc.)
• The workflow view gets increasingly compact as the viewport shrinks. At <500px, the delete/publish buttons are hidden entirely, making the view more of a navigation tool than a place for taking actions.

I also fixed some minor bugs in the workflow view as part of this work:

• The three workflow columns are now equal sizes. Previously, the margin for the gutters was subtracted from the central “In review” column, making it narrower than the others. This was not super noticeable at wide column widths, but was very clear when scaling columns down.
• Delete/publish buttons on cards are now always visible on devices that don’t support hovering.
• Delete/publish buttons are now revealed if someone tabs to them.

Examples

N.B. these videos were made including the responsive header implementation from #7825, but this PR does not include those changes. Previewing only this PR’s changes will include the non-responsive header from main, but the changes do work as standalone improvements (assuming you add the necessary <meta name="viewport"> tag).

Collections

Kapture.2026-05-23.at.17.48.04.mp4

Workflow

Kapture.2026-05-23.at.17.50.50.mp4

Notes

The workflow view’s drag/drop kanban design does not translate very well to a small touch screen. However, in this PR I focused on adapting the UI in as minimal a way as possible, so I did not change it significantly. A future improvement could be to consider making this view more touch friendly, e.g. by displaying each status stacked vertically instead of in columns. Actions moving the items between statuses could be accomplished with a drop down menu on each card instead of relying on drag/drop. (N.B. the HTML5 drag and drop backend Decap uses does not support touch screens at al).

Test plan

Extensive local testing using the test backend. Existing tests should pass. I also tested the “open authoring” mode by forcing it on in the app.

Checklist

Please add a x inside each checkbox:

• I have read the contribution guidelines.

A picture of a cute animal (not mandatory but encouraged)