Audit: identify anything not using the global class system and determine if appropriate

[zindello]

Background

A global utility class system was introduced during the UI consistency refactor (modal-input, modal-input-readonly, modal-select, cfg-input, cfg-select, modal-card, btn-*, etc.) to ensure correct dark-mode behaviour and visual consistency across the app. That refactor standardised new work going forward but didn't retrofit every existing screen.

A subsequent pass (see PR fixing issue #39) migrated all native form fields (<input>, <select>, <textarea>) to the standard class system — achieving 100% coverage on that specific element type. However, there are likely other areas of the codebase (buttons, card containers, layout elements, labels, etc.) that still use ad-hoc inline Tailwind strings where a global class already exists or should exist.

Task

Do a full audit of the codebase to identify anything not using the global class system where it would be appropriate to do so. For each finding, determine:

1. Should it use an existing global class? If yes, migrate it.
2. Is it a justified exception? (e.g. a genuinely unique one-off layout, or a runtime-dynamic value.) If yes, document why in a comment or the style guide.
3. Does it reveal a missing global class? (i.e. the same pattern appears in 3+ places with no existing class.) If yes, propose a new class in main.css.

Scope

• All .vue files in src/
• Focus on patterns that repeat across files — single-use outliers are lower priority
• Cross-reference src/assets/main.css for the full list of available global classes
• Cross-reference docs/style-guide.md for documented patterns and the inline styles audit

Known gaps already tracked

• ImportRepeaterContactsModal compact number inputs — issue Validation: ImportRepeaterContactsModal inline input styling — intentional or pre-standards gap? #53