Implement database-aware revert optimization to prevent processing undeployed modules

[pyramation]

Implement database-aware revert optimization to prevent processing undeployed modules

Summary

This PR implements a significant performance optimization for the recursive revert functionality in LaunchQL. Previously, when using lql revert --recursive, the system would process ALL modules in the workspace regardless of whether they were ever deployed, leading to unnecessary file operations, database queries, and confusing "skipping" messages.

The optimization adds database-aware filtering that queries the launchql_migrate.changes table to determine which modules are actually deployed, then filters the workspace extension list to only include those modules before processing.

Key Changes:

• Added getDeployedModules() method to query deployment status from launchql_migrate.changes table
• Made resolveWorkspaceExtensionDependencies() async with optional deployment filtering via filterDeployed parameter
• Updated revert() method to use database filtering when recursive=true
• Updated deploy() and verify() methods to handle async dependency resolution
• Fixed test file to handle async method calls
• Added comprehensive REVERT.md documentation

Review & Testing Checklist for Human

⚠️ Medium Risk - 4 critical items to verify:

• End-to-end revert optimization testing: Create a workspace with mix of deployed and undeployed modules, run lql revert --recursive, verify only deployed modules are processed (no "skipping" messages for undeployed modules)
• Error handling validation: Test revert behavior when launchql_migrate schema doesn't exist (fresh database) - should gracefully fall back to current behavior without crashing
• Backward compatibility verification: Ensure deploy and verify operations still work correctly after making resolveWorkspaceExtensionDependencies() async
• Performance measurement: Compare revert times before/after in workspace with >10 undeployed modules to verify the optimization provides meaningful speedup

Notes

Potential Risk Areas:

• Database schema assumptions: Code assumes launchql_migrate.changes table structure - could fail if schema changes
• Method signature change: resolveWorkspaceExtensionDependencies() changed from sync to async - potential breaking change for any external callers
• Database connection management: New LaunchQLMigrate clients created but may not be explicitly closed

Session Info:

• Requested by: Dan Lynch (@pyramation)
• Devin session: https://app.devin.ai/sessions/a5cdd2aebe714b9d835b800ce9f02915

The implementation leverages existing database infrastructure and follows established patterns in the codebase. Error handling includes graceful fallback when database schema doesn't exist. TypeScript compilation passes and core test structure is preserved.

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring