Fix explore page showing Install for already enabled apps

[mdmohsin7]

Summary

• The explore page (v2/apps endpoint) returns enabled: false for all apps because it uses a globally cached response with no per-user state
• Previously the client tried to patch this with _syncEnabledStateFromCache() from local SharedPreferences, but this was unreliable (stale on fresh install, cache clear, or new device)
• Added a new lightweight GET /v1/apps/enabled endpoint that returns the user's enabled app IDs from Redis (SMEMBERS — single cheap call)
• The Flutter client now fetches this in parallel with v2/apps and sets enabled from the server response
• Removed the stale _syncEnabledStateFromCache() workaround

Test plan

• Open explore page — apps that are installed should show "Open" instead of "Install" immediately
• Install a new app, go back to explore — should reflect the new state
• Pull to refresh on explore page — enabled state should persist correctly
• Fresh install / cleared cache — enabled state should still be correct (sourced from server)

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request effectively addresses the issue of incorrect 'enabled' status for apps on the explore page by fetching the user's enabled apps directly from the server. The introduction of the new /v1/apps/enabled endpoint on the backend and the getEnabledAppsServer function on the client is a clean solution. Using Future.wait to fetch app data and enabled status in parallel is a good performance optimization.

My main feedback is regarding code duplication in app/lib/providers/app_provider.dart. The logic for fetching and processing apps is repeated in both getApps and refreshAppsAfterChange methods. I've left a comment suggesting to refactor this into a shared private method to improve maintainability.

Overall, this is a solid improvement that fixes a user-facing bug and improves the data consistency of the app.