fix(ui): rank Accept-Language tags by q-value instead of substring scan

[AmirF194]

What does this PR do?

detect_ui_lang() (src/ui/http_server.c) picks the /api/ui-config language with strstr(accept_language, "zh"), so any Chinese tag anywhere in the header serves the Chinese UI, regardless of position or q-value. A bilingual browser list whose top preference is English (en-US;q=0.9,zh;q=0.5) still gets Chinese.

Per RFC 9110 12.5.4, the fix parses each tag's q-value (default 1.0), treats q=0 as explicitly unacceptable (12.5.1), and returns the highest-ranked tag whose base language is zh or en, keeping the first occurrence on a tie. This mirrors the UI bundle's own JT() fallback parser (quoted in the issue), which already does this correctly as a client-side fallback when the endpoint is unreachable.

Checklist

• Every commit is signed off (git commit -s)
• Tests pass locally (scripts/test.sh --suites httpd)
• Lint passes on the changed files
• New behavior is covered by a test (reproduce-first for bug fixes)

Verification

• The two new tests assert "lang":"en" and get "lang":"zh" on plain main; both pass on this branch. Ran both ways in a clean ubuntu:24.04 container. Full httpd suite: 66 passed, 1 skipped (pre-existing, Windows-only) on both sides.
• detect_ui_lang has a single call site (handle_ui_config); no other reader needed updating.
• cppcheck and clang-format --dry-run on the two changed files: same output before and after this change, so nothing new here.
• I have not run this on Windows or macOS; the code has no OS-specific branches, so I'd expect it to behave the same there.

Fixes #1829

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.