✨ feat: enhance admin UI configuration and SSR handling

- Add support for number chip arrays and JSON editor in admin UI config.
- Introduce pagebuilder block registry for Svelte components in admin previews.
- Implement custom role names and a 3-layer cascade model for field-level permissions.
- Add CORS configuration hierarchy for better API security.
- Update project setup instructions for admin token and config management.
- Improve SSR 404 signaling with proper context handling in NotFound component.
- Refactor routing structure to separate NotFound page into its own route.

.agents/skills/security-hardening-and-token-strategy/SKILL.md

@@ -124,6 +124,25 @@ Think in terms of:
 
 Do not rely on frontend hiding or convention where server-side permissions should be explicit.
 
+## CORS configuration
+
+CORS follows a 3-level hierarchy. Configure it in `api/config.yml` under `cors:` for project-wide settings, or in individual collection/action YAML for per-endpoint overrides:
+
+| Level | Configuration location | Scope |
+|-------|----------------------|-------|
+| Server | tibi-server `config.yml` | Global default |
+| Project | `api/config.yml` → `cors:` | Per project |
+| Collection/Action | Collection or action YAML → `cors:` | Per endpoint |
+
+Each level can `merge: true` (append to parent) or `merge: false` (replace entirely).
+
+For a project that serves a browser-based SPA to end users on its own domain and serves API/tibiadmin on separate subdomains, the default (no explicit CORS config) is usually correct since the SPA makes same-origin API calls via the BrowserSync/production reverse proxy. Add explicit CORS only when:
+- the API is called from external origins (e.g. third-party integrations)
+- the admin UI is served on a different origin than the API
+- an action endpoint needs to support cross-origin form submissions
+
+See `tibi-server/docs/02-configuration.md` (section "CORS Configuration Hierarchy") for details.
+
 ## Secure implementation patterns
 
 ### Public form endpoint