Replace `tinycolor` with tailwind

[tyler-dane]

Feature Description

Remove all tinycolor usage and package from the app

Use Case

This'll help us fully migrate away from styled-components and support theming.

Additional Context

tinycolor is at odds with tailwind. By consolidating on one styling tool, we make the code easier to read and maintain.

Implementation Options

The usual Tailwind approach is to treat hover as its own token, not something you derive on the fly.

1. Predefined hover variants in the theme
   Define both the base and the hover state and put them in the theme:
   @theme { --color-fg-primary-dark: hsl(208 13 71 / 54.9%); --color-fg-primary-dark-hover: hsl(208 13 81 / 54.9%); /* hand-picked or design token */}
   Use them like:
   class="bg-fg-primary-dark hover:bg-fg-primary-dark-hover"
   That’s the standard pattern: explicit design tokens for each interactive state.
2. Palette with shades (default Tailwind)
   The default Tailwind palette (50–950) expects you to pick two shades:
   class="bg-blue-500 hover:bg-blue-400"
   The “hover” state is just another shade from the palette, not computed.
3. Semantic color conventions
   Many systems (e.g. Radix, shadcn/ui) define states in pairs:
   --color-button-bg and --color-button-bg-hover
   or --color-primary and --color-primary-hover
   Again, each state is its own token; Tailwind just exposes them.
   Summary
   The common Tailwind pattern is:
   Define base and hover colors in the design system/theme.
   Use them with bg-{color} and hover:bg-{color}-hover (or similar naming).
   Use arbitrary values (color-mix, etc.) only when you need a one-off deviation from the theme.
   So the “standard” way for this project would be to add --color-fg-primary-dark-hover to the theme and use hover:bg-fg-primary-dark-hover instead of deriving the color on hover.