feat: admin panel support with notifications and posts

[Destinea]

Summary

This PR expands DevKit with the shared database and design-system contracts required by ClashKing's mobile content, push notifications, feature flags, and dedicated operations admin panel.

Database

• Restores the canonical migration history from 009_app_announcements.sql through 016_dashboard_role_grants.sql after rebasing on main.
• Adds 017_mobile_admin_operations.sql for mobile device state, notification preferences, posts and revisions, localized campaigns, delivery attempts, administrator sessions, audit events, feature flags, and KPI snapshots.
• Migrates legacy app_announcements rows into admin_posts and retires the superseded table.
• Uses idempotent upgrades for databases that already contain pre-merge admin tables, including translations, target_locales, and send_time.
• Adds 018_schema_history_reconciliation.sql to repair development databases affected by the former 009-012 version collision.
• Includes the indexes and constraints required by ClashKingAPI, ClashKingTracking, ClashKingApp, and ClashKingAdminPanel.

Shared design system

• Adds the warm graphite ck-theme-operations theme for operational and admin surfaces.
• Adds reusable data-heavy web primitives for metrics, toolbars, progress indicators, tabular values, selects, flat rows, and icon tiles.
• Adds shared danger-button, disabled-toggle, focus, and operations-theme control states so consuming products do not need local overrides.
• Aligns web elevation, corner radii, surface treatment, and nested rows with the Flutter application's flatter visual language.
• Extends the Flutter package and documentation with the corresponding shared tokens and components.

Validation and documentation

• Strengthens repository and design-system validation in CI.
• Updates database, mobile design, component, governance, and cross-repository contract documentation.
• Documents ownership boundaries so reusable primitives remain in DevKit while product-specific composition stays in each application.

Validation

• goose -dir database/timescale validate
• Full Goose migration run from 001 through 018 on a temporary empty Timescale database
• Upgrade of the existing local database from Goose version 12 through 18
• ClashKingAPI go test ./... and runtime smoke tests
• ClashKingAdminPanel API go test ./..., frontend production build, and /healthz smoke test
• ClashKingTracking go test ./...
• npm run check in design