[FEAT]: Migrate frontend styling to Tailwind CSS

[marcvergees]

📝 Description

Migrate the FireForm frontend styling to Tailwind CSS (utility-first approach) and remove the existing global/CSS-in-JS/SCSS styles where appropriate. This work covers the app shell, core UI components (forms, inputs, buttons, modals, etc.), layouts, and documentation examples so that the entire frontend uses Tailwind utilities and configured design tokens.

💡 Rationale

• Standardize styling across the codebase using a utility-first system.
• Reduce CSS bundle size by using Tailwind's purge/JIT and centralized design tokens.
• Speed up developer workflows and make styling of components more consistent and maintainable.
• Improve theming and accessibility by centralizing tokens in tailwind.config.js.

🛠️ Proposed Solution

Implementation approach (incremental):

• Add Tailwind CSS, PostCSS setup and configure tailwind.config.js and purge/JIT for the current build system.
• Create shared design tokens (colors, spacing, typography) in tailwind.config.js and map existing variables to tokens.
• Convert core components first (form controls, buttons, layouts), then convert pages and examples.
• Update Storybook / component docs and any design examples to use Tailwind classes.
• Replace or remove legacy global styles / stylesheet files as components are migrated.
• Add a migration guide in docs/ describing conventions, token names, and examples.
• Add visual regression checks or manual QA steps to validate there are no regressions.

Suggested milestones / phasing:

• Phase 1: Tailwind setup + design tokens + build integration
• Phase 2: Migrate core components (forms, inputs, buttons)
• Phase 3: Migrate pages, examples and docs
• Phase 4: Remove legacy CSS and finalize QA

✅ Acceptance Criteria

• Tailwind is integrated into the repository and the project builds successfully.
• Tailwind design tokens are defined (colors, spacing, typography) in tailwind.config.js.
• Core components (forms, inputs, buttons) are migrated to use Tailwind classes.
• Storybook / component documentation updated to reflect the new styles.
• A migration guide is added to docs/ describing the approach and conventions.
• No major visual regressions on primary pages (validated via visual tests or manual QA).

📌 Additional Context

• Keep migration incremental to minimize disruption; prefer small PRs per component or feature area.
• If the repository uses a specific build tool (Vite, Webpack, Next.js, etc.), adapt the PostCSS/Tailwind setup accordingly.
• If helpful, we can add an example PR that converts a single component as a reference for the team.