Follow the settings modal through its consumers: search palette deep links and the user manual

Follow-up to FR-3903, which moved the user settings from a page to a modal driven by `?settings=`. Two consumers still describe the old shape.

### Search palette

`buildHits` hardcodes `?tab=` when it targets a setting row, and resolves a setting's breadcrumb tab by `param === 'tab'`. The settings modal drives its categories from `?settings=`, so a palette hit for a setting lands without a category and its breadcrumb loses the category name. The param belongs to the index entry and should be read from it.

The redirect shim also rebuilds the query string from scratch, dropping the `?setting=` key the palette adds to scroll to one row.

### Deep links landing on an empty shell

The shim only moves the modal onto the page the user was on when it has to convert a legacy `?tab=` link. A link that already carries `?settings=` sits on `/usersettings` over an empty shell even when there is a page to open over.

### User manual

`user_settings.md` and `header.md` in all four languages describe a page with four tabs, a group list on the left of the General tab that `hideGroupNav` removed, and a `Logs / Errors` dropdown item that no longer exists.

The `` / `` / `` anchors must keep their ids — `helpAnchors.json` resolves the help button against them.

JIRA Issue: FR-3904

Start by reading buildHits and the redirect shim, then compare their query handling with the settings modal’s ?settings= and ?setting= links. Review user_settings.md, header.md, and helpAnchors.json across all four languages. Done means palette links preserve the category and row, deep links open over the current page, and the manuals describe the modal while retaining the required anchor ids.

Written by the indexing model from the issue text.