feat(cabana): read-only Plugins screen with installed plugins

- GET /plugins (backend.view_plugins, superusers always pass) lists the
  plugins from party.Installed, or party.Activated IDs for older builds,
  with the built framework version and whether the registry is configured
- Settings -> System -> Plugins entry with the new SettingsEntry.path,
  added only for principals allowed to open it
- PluginsView at /system/plugins with an Installed tab (reka-ui Tabs);
  settings panel, rail, breadcrumbs and page title know the route
- OpenAPI and SPA types regenerated; contract, token-class and
  conformance inventories list the route; en/pl strings; docs

docs/backend/admin-spa.md

@@ -41,6 +41,10 @@ The button at the top of the plugin rail switches the theme: each click moves fr
 
 When the server offers more than one admin language (`meta.locales` of `GET .../lang`), the user menu lists them under Language, each named in its own language. Choosing one saves it as the administrator's `locale` preference, caches it in `localStorage` (`summer-admin.locale`) and reloads the page, so the strings, navigation, settings, schemas and validation messages all come back in that language, in any browser and whatever `Accept-Language` says. A form with unsaved changes asks before the reload.
 
+## Plugins screen
+
+Settings → System → Plugins opens `<prefix>/system/plugins`, a read-only screen for administrators holding `backend.view_plugins` (`cabana.PermissionViewPlugins`; superusers always pass). Its Installed tab lists the plugins the binary was built with, from `GET <prefix>/api/v1/plugins`: the name and description from each plugin's `plugin.yaml` (only the ID for a plugin without one), the version and where the plugin came from (Go module, git submodule or the application itself), with the framework version the application was built with above the tabs. The settings entry carries a `path` instead of a controller, so the settings index, the settings panel and the breadcrumbs treat the screen like any other System entry. The SPA never calls the plugin registry itself; see [Publishing plugins](../plugins/marketplace.md#admin-plugins-screen).
+
 ## New versions
 
 A tab opened before a deploy would otherwise keep running the old admin against the new server, because the session refreshes silently. The SPA reads the build it booted with from the `summer-admin-build` meta of the served `index.html` and asks `<prefix>/build.json` again when the window gets focus, when the tab becomes visible and every 5 minutes while it is visible, at most once every 30 seconds. When the server answers a different build, a banner at the bottom right says that a new version is available, with Reload and Close buttons. The SPA never reloads by itself: Reload goes through the usual page reload, so a form with unsaved changes still asks first, and Close hides the banner until yet another build is deployed. When the served index carries no build, as under the Vite dev server, the check is off.