Open user settings in a modal over the current page instead of a separate page

`/usersettings` is a full page today: opening Preferences or Logs navigates away from whatever the user was doing, and coming back means navigating again. Settings are a detour from the task at hand, not a destination.

Make the settings surface a modal that opens over the current page, the way a desktop app's settings window does: a category rail on the left, the selected pane on the right, and the page the user was on still behind it.

### Scope

- A dialog built on `BAIModal`, with the four existing categories as a left rail: General, Logs, Login Sessions, Login History.
- Driven by a `?settings=` query param on the current location, so refresh restores it, Back closes it in one press, and the URL stays shareable.
- `/usersettings` stays a real route, as a shim that converts the legacy `?tab=` deep links onto the param. It cannot be deleted: `ContainerCommitModal` stores `to: '/usersettings?tab=logs'` as a string in a notification.
- Below the `md` breakpoint the dialog goes fullscreen and the rail becomes a drill-down with a back button.

### Constraints

No functional regression. Every setting, the log list, login sessions and history, and the child modals opened from General (My Keypair, SSH Keypair Management, both shell script editors, the reset confirmations) keep working exactly as they do now, with the same `data-testid`s. This is a UI/UX change only.

### Out of scope

- Regrouping the four categories into a finer rail.
- Updating the user manual, which still describes a page with four tabs. The `#user-settings` / `#general-tab` / `#logs-tab` headings must stay byte-identical either way, because the help button resolves its anchors against them.

JIRA Issue: FR-3903

Start at the existing /usersettings route and the BAIModal entry point; inspect how the four categories, child modals, and legacy ?tab= links are currently wired. Done means the settings modal preserves the current page, query-param navigation and route shim work, the responsive drill-down behaves as specified, and existing settings, data-testid values, and child modals remain functional.

Written by the indexing model from the issue text.