[Task](greenhouse): Evaluate and implement cn utility for className management

[ArtieReus]

Task Description

Evaluate whether to adopt the cn utility function (combining clsx + tailwind-merge) for className management across the greenhouse app, as suggested in PR #1549 review comment.

The cn utility provides cleaner syntax for combining classNames, handles conditional classes gracefully, and resolves conflicting Tailwind CSS classes automatically.

Sub-tasks

• Audit current className patterns in greenhouse codebase
  • Count template literal usage: className={...}
  • Identify conditional className logic that could benefit from cn
  • Find potential Tailwind class conflicts
• Check dependency status across monorepo
  • Verify if clsx and tailwind-merge are already installed in other packages
  • Check if other apps (supernova, exampleapp) use similar utilities
• Assess value vs cost
  • Estimate number of files that would benefit from refactoring
  • Analyze bundle size impact of adding dependencies
  • Evaluate code consistency improvements
• Make recommendation
  • Document findings and recommendation (adopt project-wide, selective, or skip)
  • If adopting: create implementation plan
• Implementation (if approved)
  • Add clsx and tailwind-merge dependencies
  • Create src/lib/utils.ts with cn function
  • Set up TypeScript path alias @/lib/utils (if needed)
  • Refactor existing code to use cn utility
  • Update documentation/guidelines

Related Issues

• PR fix(greenhouse): remove whitespace below PluginNav in shell layout #1549 - Layout fix where the suggestion originated

Additional Context

Currently, the codebase uses template literals for className concatenation:

<div className={`greenhouse-shell ${shellStyles}`}>

The proposed approach would use:
<div className={cn("greenhouse-shell", shellStyles)}>

This is especially valuable for:
- Conditional classes: cn("base", isActive && "active")
- Tailwind conflicts: cn("px-4", "px-6") → results in "px-6"

Decision needed: Is this utility worth adopting project-wide, or is the current approach sufficient?