[2.x] fix: don't stack multiple phone header controls on top of each other

[imorland]

Changes proposed in this pull request

App-primaryControl is a documented extension point, so a page can carry more than one header control — core's "start discussion" button plus, for example, an extension's follow button on a tag page. On phones every control is positioned absolute; right: 0, which assumes a single occupant: with two present they render in exactly the same 51×46 box, appearing as one smudged glyph.

Where the controls share a parent (they are list items of the same nav), that parent now becomes a right-anchored flex row and the controls return to relative positioning, so the browser places them side by side at whatever width each one is — no hard-coded control width to drift out of sync with the button padding.

The rule is selected with :has(> .App-primaryControl ~ .App-primaryControl), so it engages only when a second control actually exists; single-control pages keep their existing geometry by construction. :has() is already used in core (forum/PostStream.less), so this breaks no new ground on browser support.

Measured at 390px, authenticated

Page	Before	After
Tag (two controls)	both at x=339 → 390 — overlapping	288 → 339 and 339 → 390
Index	339 → 390	unchanged
Discussion	350 → 390	unchanged
User	no primary controls	unchanged

Reviewers should focus on

• Whether other layouts put sibling App-primaryControl items in a container where making the parent a flex row could have side effects. I checked index/discussion/tag/user at phone width and the single-control pages are unaffected, but extension-heavy forums may have combinations I can't see.
• Deliberately not in scope: no markup change (extensions and themes targeting .App-primaryControl keep working as-is), and no overflow strategy — with three or more controls at 390px the title will eventually collide, which is a separate design question rather than something to smuggle in here.

On testing

This is pure CSS geometry, and I could not write a suite test that fails first for it: a LESS-compiling PHPUnit test can only assert that declarations exist (implementation-coupled, and blind to actual overlap), and jsdom has no layout engine, so getBoundingClientRect() returns zeros. The red/green gate was a headless-Chrome probe measuring the real boxes on a live forum — overlap detected before, absent after, other pages unchanged (the table above). Core having no browser-based visual testing is the underlying gap here; worth its own discussion.

Confirmed

• Frontend changes: LESS only — verified live at phone width across four page types; JS suite (294 tests) green.