fix(dashboard): truncate the channel and status pane heading

[rmyndharis]

.chats-page .chats-room-header h2, the heading of the channel and status panes, carried none of the truncation its twin .chats-page .room-contact-info h3 has. A title with no break opportunity therefore kept its full natural width, ran past the panel, and was cut mid-glyph by .chats-layout { overflow: hidden } with nothing to signal that text was missing. Neither pane exposed the untruncated value anywhere.

What changed

• white-space: nowrap, overflow: hidden and text-overflow: ellipsis on that heading. overflow: hidden is the load-bearing one: it both clips and zeroes the flex item's automatic minimum, so the other two engage without a min-width here or on any ancestor.
• title on both headings, so the full text is recoverable: activeChannel.name for the channel pane, and for the status pane the name ?? pushName ?? id chain, hoisted to activeStatusTitle so the heading and its tooltip read one expression rather than two copies.
• The comment above .chats-page .chats-room-header > svg { flex-shrink: 0 } is rewritten. It claimed both of the icon's siblings opted out of shrinking and that the icon was the only flexible item in the row. Neither was ever true: .room-back is display: none above the mobile breakpoint, and the heading has always had flex-shrink: 1, resting only on its automatic minimum. Truncating the heading removes that minimum, so the heading now shares the deficit. Mutation-tested by removing the opt-out and re-rendering: the icon lands at 0px on main against 1.2px to 4.5px on this branch at a 769px viewport, so the rule stays load-bearing and only its stated mechanism moved.

Impact

Measured in headless Chromium with the real webfont and the production globals, across both navigation states, at 900px and 1024px viewports, with unbroken titles of 40 and 60 characters. Before, the heading never shrank in any of the 8 cells, its rendered width equalling the natural text width, and it overhung the layout edge by up to 392px. After, it stops 24px inside the edge, which is the header's own right padding, and the ellipsis engages in 7 of the 8 cells. The eighth is the one case where the title genuinely fits, 417px natural against 417px available, so no ellipsis there is correct. The header's own scrollWidth drops to exactly its clientWidth in every cell, so it no longer overflows at all.

Behaviour change worth knowing before reviewing screenshots: titles that do have spaces used to wrap. With the production line-height: 1.6 a 58 character spaced name and the navigation expanded rendered on 3 lines, 77px tall, at a 900px viewport and on 2 lines, 51px, at 1024px. The header is fixed at 70px, so the 900px case was not merely tall, it escaped the header and painted over the message feed. It now renders on one line of 26px in both. At the narrow end that is a fix rather than a restyle.

Verification

• The 8 cell sweep above, run against this branch and against main. The discriminating assertion is scrollWidth staying at the natural text width while clientWidth collapses to the available width, with a non-visible overflow. A bounding rect alone is not sufficient evidence here: min-width: 0 on its own moves the rect inside the edge while the text pixels still run to it unchanged, which is why it is not part of this change.
• Selector reach confirmed two ways of different kinds: a literal grep, and enumerating the parsed rules through the browser's own CSS engine (184 selectors), which agree that exactly one rule targets this heading and that .chats-room-placeholder h2 is a disjoint selector left untouched.
• Dashboard lane locally: lint, format:check, typecheck, i18n:check, build, test:unit, all pass. Docs lane test:docs passes, 264 tests.
• No automated regression test for the three declarations. jsdom reports zero for every geometry, so nothing in the dashboard lane can distinguish them present from absent, and the repository has no visual-regression rig. The TSX half is observable in jsdom, but the heading and its tooltip read the same single expression in both panes, so there is no second copy that could drift out of step.

Notes

The tooltip is a pointer affordance. On the single-pane touch layout below 768px there is no hover, so a truncated title is not recoverable there; the ellipsis still signals that it is truncated.

The changelog entry sits at the same anchor as the one in #1425. Whichever lands second will conflict there and needs a one line rebase. A conflicted PR in this repository gets no CI run at all and reports "no checks reported", which reads as pending rather than as never going to run, so re-check the second PR after rebasing.

Fixes #1423