[2.x] fix: stop the admin users heading inheriting the list header layout

[imorland]

Fixes #4987

Changes proposed in this pull request:

AdminPage gives the AdminHeader a class derived from the page's own — `${className}-header` — so the users page header is rendered as <div class="AdminHeader UserListPage-header">. That's the same class UserListPage uses for the toolbar row above the grid (search, user count, Create User), and UsersListPage.less styles it as a flex row. The page header therefore picked up display: flex, which turned its .container child into a flex item; .container's margin: 0 auto then centred it, leaving the gap to the left of "Users" on narrow viewports.

• The flex rule is scoped with :not(.AdminHeader), so it applies only to the toolbar row it was written for.

I've scoped the selector rather than renaming the inner element's class. Renaming reads better, but UserListPage-header is a public-ish hook that themes and extensions may target, and I'm not willing to break that during RC for a cosmetic fix.

A note on the bottom margin: the header was also inheriting margin-bottom: 16px. Both selectors are single-class, and admin.less imports AdminHeader before UsersListPage, so 16px was winning over the 20px that .AdminHeader declares for itself. With the rule scoped, the header goes back to 20px and matches every other admin page. It's a 4px change below the heading, and it's the value the header was always meant to have. Nothing else was inherited — align-items and column-gap do nothing without display: flex.

This isn't new in 2.x. The collision has been there since #3744 (May 2023) and is present in 1.8; it's worth fixing for GA because it's cheap and it's on a page every admin sees, not because it's a regression.

Reviewers should focus on:

• That the toolbar row is genuinely unaffected. It's a bare className="UserListPage-header" string literal with no classList merge, so it can never carry AdminHeader and still matches the scoped selector.
• Whether reverting to the 20px margin is wanted here, or should be left to a follow-up.

Necessity

• Has the problem that is being solved here been clearly explained? — the "Users" heading is centred on mobile while every other admin heading is left aligned.
• If applicable, have various options for solving this problem been considered? — scoping the selector vs renaming the inner class; scoping avoids breaking anything targeting the existing name.
• For core PRs, does this need to be in core, or could it be in an extension? — both the class collision and the stylesheet are in core.
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation. — reproduced on the Users page at mobile width; checked the toolbar row below still lays out inline.
• Frontend changes: tests are green — no JS changes.
• Frontend changes: tests have been added. — this is a one-selector stylesheet change; there's no CSS test setup in the repo, and the only assertion available in jest (that the header carries both classes) would describe the collision rather than the fix.
• Backend changes: tests are green — no backend changes.
• Backend changes: tests have been added, or are not appropriate here — n/a.
• Where applicable, changes are suitable for all supported database drivers (MySQL, MariaDB, PostgreSQL, SQLite). — no database involvement.
• The description above is written by me and describes what this pull request actually does.

Required changes:

• Related documentation PR: (Remove if irrelevant)