Admin settings API integration: consume /api/settings

[Seme30]

Problem

The C# backend now exposes the remaining admin Settings functionality through /api/settings, but the frontend still uses the Razor settings handlers. The frontend needs an integration pass against the new API contract.

Current gaps

• No frontend client consumes the global site message endpoints.
• No frontend client consumes ETL or theme settings.
• Search visibility and report-type text updates still use Razor handlers.
• Metadata parameter management still uses the Razor Tags page.
• Role, user-role, and group-role administration still uses Razor handlers.
• No frontend tests cover successful updates, validation, or forbidden responses.

Backend API now available

• GET/POST/DELETE /api/settings/site-messages
• GET/PUT /api/settings/etl
• GET /api/settings/etl/default
• GET/PUT /api/settings/theme
• GET /api/settings/search
• PUT /api/settings/search/{type}/visibility
• PUT /api/settings/search/report-types/{id}/text
• GET/POST/DELETE /api/settings/tags/{type}
• Role, user-role, and group-role endpoints under /api/settings

Mutating endpoints enforce the existing Settings permissions, including Manage Global Site Settings, Create Parameters, Delete Parameters, Edit Role Permissions, Edit User Permissions, and Edit Group Permissions.

References

• Backend branch: feat/settings-api
• Backend commit: 5339ae66
• web/Controllers/Api/SettingsApiController.cs
• web/Contracts/Api/Settings/SettingsDtos.cs
• Legacy handlers: web/Pages/Settings/

Definition of done

• The frontend Settings experience consumes /api/settings instead of the Razor handlers.
• Site messages, ETL, theme, search, metadata, roles, user roles, and group roles work end to end.
• Permission failures are shown clearly to the user.
• Frontend tests cover representative reads, writes, validation, and forbidden responses.
• Typecheck and lint pass.
• No frontend Settings flow depends on the legacy Razor page handlers.