fix(dashboard): swap the chat panes where two do not fit

[rmyndharis]

With the navigation expanded the chat room is viewport - 646, so between the mobile breakpoint and 888px it is narrower than the composer's own minimum. The send button sat outside the clip of .chats-layout, with no scrollbar to recover it, and the text field had already collapsed to a zero pixel content box, so a user could neither see what they typed nor click send. #1425 moved the threshold from 1014px down to 859px; this closes the rest.

Why not narrow the chat list

That was the plan recorded on #1422, and measurement rejected it. The budget at 769px is 443px, and the composer needs 214px, so the sidebar would have to fit in 229px. Its own header does not: the search input floors it at 245px in English, and in French the tab row "Discussions / Chaînes / Statut" floors it at 270px. Reaching 229px would have taken four more rules (a tab ellipsis, a min-width on the search input, hiding the kind badge) and still handed back a 30px text field.

What changed

• Below 889px with the navigation expanded, the panes swap one at a time rather than sitting side by side, which is what the page already does below the mobile breakpoint. The room goes from 123px to 443px at the narrow end.
• The band is bounded on both sides. At 768px and below the mobile shell owns the layout; from 889px the room fits the composer again. Only the pane-swapping rules are in the band, not the mobile shell's padding and height, which would collapse the panel to 191px inside a desktop shell.
• It is keyed to the navigation as well as the viewport, since the room is viewport - 646 only while the nav is expanded. With it collapsed the room already fits at every width, and nothing here applies.
• .chats-page .message-text-input gains a 64px floor. It could previously shrink to its own padding and border and render a text box exactly 0px wide.

Impact

Measured in headless Chromium against this branch, with the real webfont and the production custom properties and element defaults.

Navigation expanded:

Viewport	Send button before	Send button after	Visible text before	after
769px	90px outside	25px inside	0px	205px
800px	59px outside	25px inside	0px	236px
858px	1px outside	25px inside	0px	294px
888px	inside	25px inside	0px	324px
889px	inside	flush on the edge	0px	30px
900px	inside	11px inside	16px	30px
960px and wider	inside	unchanged	unchanged	unchanged

The send button is no longer outside the clip at any width, and the text field is never zero.

Verification

• The band, its two boundaries, and the handback measured on the branch file itself, cross-checked against main.
• Navigation collapsed: byte-identical to main at 769, 858, 889, 900 and 1024px. That state was never broken and is untouched.
• At 768px and below: byte-identical to main, so the mobile shell is unaffected.
• With no chat open, the band gives the list the whole panel and hides the room, matching the mobile behaviour.
• The panel does not collapse: .chats-page stays 649px and .chats-layout 569px inside the band, against the 239px/191px they would take if the mobile shell's rules had been ported with them.
• The 64px floor is inert wherever there is room: identical geometry from 960px up and on a 320px phone. It binds only between 889px and 959px.
• Dashboard lane locally: lint, format:check, typecheck, i18n:check, build, test:unit. Docs lane test:docs, 264 tests. The page-CSS scope gate passes, 11 of 11.

Follow-ups this does not cover

Two overflows sit inside the two-pane range that remains and are not caused by this change: .chats-page .replying-to-title has no overflow handling, so a long unbreakable quoted name paints across the close button, and the location message's map thumbnail carries an inline maxWidth: 220 with no max-width: 100%, so it passes the clip once the room is narrower than that. Both are filed as #1428.

Fixes #1422