Establish server-rendered templates and an asset pipeline

Plan and implement the identity platform's browser-facing foundation before full identity flows. Confirmed intent: - Provide a CSS pipeline, a small JavaScript library for browser-only/progressive enhancements, an asset builder, and consistent server-side template conventions. - Preserve the existing separation of application operations from HTTP and UI. - Compile-time rendering/rebuild trade-offs are acceptable: keep incremental Rust builds in development. The UI surface is small but critical. The user finds literal HTML verbose and has approved Maud's Rust-native markup and component functions. Approved implementation choices: - Vite for development asset serving/CSS updates and production manifest-based hashed assets, with no Node runtime required in the built application. - Stimulus for small enhancement controllers; essential content and forms remain functional without JavaScript. - Use Maud for compile-time server rendering, with compact html! syntax and ordinary typed Rust component functions in dedicated view modules. User approved this choice and accepts incremental rebuilds. Do not introduce a custom template DSL/preprocessor without demonstrated need. - Start with modern custom CSS, tokens and component styles, following the proposed default. Support light and dark palettes from the start using prefers-color-scheme and semantic tokens; both must work without JavaScript, including forms, validation, focus, and browser-native controls. No Tailwind or client-side application framework. User requested a proper icon-font library: use self-hosted Bootstrap Icons through Vite (without Bootstrap CSS), a typed Maud icon helper, decorative aria-hidden glyphs, and visible labels for controls. No CDN or inline SVG dependency for UI icons. Acceptance scope: - One development entry point coordinates Rust and the asset server, with explicit loopback-only development settings and cleanup. - Shared layout and small accessible presentation primitives; typed page view models; no business logic in templates. User additionally requested ready-made table and related components: include semantic responsive data tables, status badges, empty states, and pagination alongside form controls. Demonstrate fictional data only, without adding API writes, fake sorting, or a generic client-side grid. - Explicit stylesheet delivery works with JavaScript disabled in development and built mode. Asset resolution handles the build manifest and dependencies without hardcoded hashes; production mode never references the development server. - Demonstrate a non-sensitive component/styleguide page, one small enhancement, and browser checks with/without JavaScript in light and dark color schemes. Verify asset headers/CSP and responsive layout. Keep the existing demo bearer token out of HTML and JavaScript; authenticated forms require a separate browser-session/CSRF design. - Establish CSP-compatible script conventions, local assets, missing-manifest/error behavior, and project-appropriate build/tests. Implemented in /home/mathias/work/identity-platform; changes remain uncommitted. Maud layout/components live under src/frontend and feature-local styleguide views under src/features/styleguide. Vite/Stimulus/custom CSS and self-hosted Bootstrap Icons live under frontend, with locked npm dependencies, explicit stylesheet delivery, system light/dark palettes, and no CDN/custom client environment exposure. The public /dev/ui preview is non-sensitive and only validates fictional GET input. Shared components include configurable text fields, notices, scoped-header responsive tables with compile-time column counts, status badges, empty states, native pagination links, and a typed decorative icon helper. Assets have explicit development/built/disabled modes. Built mode loads and validates manifest members, dependency CSS/fonts/favicon, paths and files at startup, serves only the in-memory allowlist with MIME/nosniff/immutable caching, and uses same-origin CSP. Development permits only its configured loopback Vite origin/socket, with CSS HMR and incremental Rust builds. Dev tooling retains the last healthy server through compile failures, reloads browsers after successful rebuilds, rejects occupied ports without killing other services, handles recently closed TIME_WAIT ports, strips identity credentials from Vite, and cleans up its owned process groups. Verified outcomes: - Cargo fmt, strict all-target/all-feature Clippy, 31 Rust tests including synthetic PostgreSQL integration, 5 Python dev-tool tests, locked npm ci, asset checks/build, Python syntax and whitespace checks pass. - Automated real-Chrome/Playwright acceptance passes all 8 combinations of development/built, light/dark, and JavaScript on/off. Checks cover native form validation/reset/escaping, reveal state, icon font loading, table semantics, selected contrast, keyboard/skip focus, 320px/390px overflow containment, asset MIME/cache/CSP headers, and absence of unexpected external requests or console errors. - Direct real-browser checks verify CSS hot updates without navigation and Rust-ready full reload. A deliberate compiler error kept the previous server serving HTTP200; restoring source produced a new healthy process. Temporary probes were removed. - UI screenshots were visually inspected. README and frontend/README.md document setup, components, modes, safety, themes/icons, and browser gates. Owned test sessions were stopped and their ports released; no production services or existing port files were modified. Limits: this is an English-language component preview, not an authenticated administration UI. Browser sessions, CSRF-protected mutations, identity flows, localization catalogs, manual persisted theme selection, sorting/data-grid behavior, and deployment are not implemented. Browser accessibility checks are focused coverage, not a full accessibility audit. Database diagram documentation remains at committed b766ed5.