[2.x] Implement content negotiation for forum error handling

[dsevillamartin]

Fixes #3850

Changes proposed in this pull request:

• Create a error handler for the forum that determines whether to forward to JSON or HTML view
  • Use JSON API Formatter for forum errors if the request did not explicitly state text/html in Accepts header
  • Fixes /login route not returning JSON from forum
  • Fixes HighMaintenanceModeHandler not returning JSON for requests initiated by forum (uses isApiRequest, and our requests do not set the header)

Reviewers should focus on:
I added the bitworking/mimeparse package (last updated end of 2025) to parse more complex Accepts headers (eg. with quality priority). It looks like browsers basically always (wasn't able to find concrete evidence of this) have text/html in their Accepts. While our XHR requests have Accepts: */*.

However, this did make isHtmlRequest a weaker check that could be true at the same time as isApiRequest (due to the quality priorities). I think properly parsing with this package makes sense, however, perhaps isHtmlRequest should just be the negation of the stronger isApiRequest check (made this change)? Additionally, isHtmlRequest is only used in LogInController for the maintenance login error validaiton.

I also thought that adding this check to the forum-wide error handler made more sense than just the login route alone.
Plus, I didn't think just slapping an Accepts header to our JS requests was the proper solution.

Screenshot

Necessity

• Has the problem that is being solved here been clearly explained?
• If applicable, have various options for solving this problem been considered?
• For core PRs, does this need to be in core, or could it be in an extension?
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run composer test).
• Core developer confirmed locally this works as intended.
• Tests have been added, or are not appropriate here.

[imorland]

Pushed some hardening and test coverage on top of this (9e85a3bc9) ahead of considering it for 2.0.0-rc.3. 👍

Hardening RequestUtil::getPreferredContentType()

While adding tests I found that this helper — now reached on the error-handling path via ContentNegotiationFormatter — can blow up in two ways, turning an error response into a second, fatal error:

1. null return → TypeError. Mimeparse::bestMatch() is typed ?string and returns null when the Accept header matches none of the offered types (e.g. Accept: application/xml or text/plain). The method is declared : string, so that's an uncaught TypeError. This is easy to trigger from the wild (bots, proxies, odd clients).
2. Malformed Accept → warning + UnexpectedValueException. A media range without a subtype makes bestMatch() emit an E_WARNING and throw.

Both now fall back to an empty string (treated as "not an API request" → HTML), so a hostile or unusual Accept header can't escalate. The @ suppresses the library's warning and the catch swallows the throw — deliberately, since this is defensive code in the error handler.

Tests added

• RequestUtilTest (unit) — isApiRequest / isHtmlRequest / getPreferredContentType across JSON:API, plain JSON, */*, empty, typical-browser, unrelated, and malformed headers (explicitly pinning the never-throw and null→'' behaviour, plus documenting that an empty Accept is treated as API).
• ContentNegotiationFormatterTest (unit) — API requests delegate to the JSON formatter, browser requests to the HTML formatter.
• ErrorNegotiationTest (integration) — a forum route that errors is negotiated through the full middleware stack: JSON for */* (the LogInController doesn't handle validation exceptions properly #3850 regression) and application/vnd.api+json, HTML for browser Accept.

All green locally (13 unit + 3 integration) and PHPStan is clean on the changed files. This checks the "Tests have been added" box.