Architecture: Unify overlay modal system to eliminate code duplication and improve maintainability

[coderabbitai]

Problem Statement

The current modal system in superfile suffers from significant architectural inconsistencies and code duplication that makes the codebase harder to maintain and prone to bugs.

Current Modal Types

We currently have six different overlay modal implementations:

1. Typing Modal - for creating files/directories
2. Prompt Modal - for user prompts and confirmations
3. Help Menu Modal - for displaying keyboard shortcuts
4. Notify Modal - for notifications and warnings (recently refactored)
5. Sort Options Modal - for file sorting preferences
6. First Use Modal - for initial user introduction

Key Problems

1. Scattered Input Handling Logic

Each modal implements its own input handling in different locations across the codebase:

• Key handling is spread across multiple functions (mainKey, normalAndBrowserModeKey, notifyModelOpenKey, etc.)
• No consistent pattern for modal navigation, confirmation, or cancellation
• Modal-specific keypresses are handled in different ways, making it difficult to maintain consistent UX

2. Duplicated Rendering Code

Modal rendering shows significant code duplication:

• Each modal reimplements similar border styling, sizing, and positioning logic
• Common UI elements like confirm/cancel buttons are recreated multiple times
• Inconsistent styling patterns across different modals
• Manual newline and spacing management in each render function

3. No Modal State Coordination

Currently there's no mechanism to guarantee only one modal is open at a time:

• Multiple modals could theoretically be opened simultaneously
• No central modal state management
• Risk of UI conflicts and undefined behavior when multiple overlays are active
• Difficult to track which modal currently has focus

4. Inconsistent State Management

Each modal manages its state differently:

• Some use boolean open fields, others use more complex state machines
• Different initialization and cleanup patterns
• Inconsistent update/message handling approaches
• No unified lifecycle management

5. Testing and Debugging Complexity

The scattered implementation makes testing difficult:

• Each modal requires separate test setup and teardown
• No consistent way to test modal interactions
• Debugging modal-related issues requires knowledge of multiple different patterns

Impact on Development

This architectural fragmentation:

• Increases development time for new modal features
• Creates maintenance burden when fixing modal-related bugs
• Introduces inconsistencies in user experience
• Makes code reviews harder due to different patterns across modals
• Complicates testing of modal interactions

Target Achievements

A unified modal system should achieve:

• Single source of truth for modal state management
• Consistent input handling patterns across all modal types
• Reusable rendering components to eliminate duplication
• Guaranteed exclusivity - only one modal active at a time
• Simplified testing through standardized modal interfaces
• Easier maintenance through centralized modal logic
• Consistent UX patterns across all overlay interactions

Current Technical Debt

The recent refactoring work (PR #979) shows progress toward unification with the new notify package, but this only addresses one modal type. The remaining five modals still follow the old scattered patterns, creating a mixed architectural approach that needs completion.

Related to: #979
Reported by: @lazysegtree