feat(followup): implement PLAN-FOLLOWUP.md gap fixes

Complete implementation of 7 slices addressing E2E testing gaps:

Slice 0+1: Wire Actions + ReasonPrompt
- FocusView now uses useActions hook instead of direct act() calls
- Added pendingAction state pattern for skip/defer/complete actions
- ReasonPrompt integration with proper confirm/cancel flow
- Tags support in DecisionEntry interface

Slice 2: Drag Reorder UI
- Installed @dnd-kit (core, sortable, utilities)
- QueueView with DndContext, SortableContext, verticalListSortingStrategy
- SortableQueueItem wrapper component using useSortable hook
- pendingReorder state with ReasonPrompt for reorder reasons
- Cmd+Up/Down keyboard shortcuts for accessibility
- Fixed: Store item ID in PendingReorder to avoid stale queue reference

Slice 3: System Tray Integration
- tray.rs with TrayState, setup_tray, toggle_window_visibility
- Menu with Show/Quit items
- Left-click toggles window visibility
- update_tray_badge command updates tooltip with item count
- Frontend wiring in AppShell

Slice 4: E2E Test Updates
- Fixed test selectors for InboxView, Queue badge
- Exposed inbox store for test seeding

Slice 5: Staleness Visualization
- Already implemented in computeStaleness() with tests

Slice 6: Quick Wiring
- onStartBatch callback wired to QueueView
- SyncStatus rendered in nav area
- SettingsView renders Settings component

Slice 7: State Persistence
- settings-store with hydrate/update methods
- Tauri backend integration via read_settings/write_settings
- AppShell hydrates settings on mount

Bug fixes from code review:
- close_bead now has error isolation (try/catch) so decision logging
  and queue advancement continue even if bead close fails
- PendingReorder stores item ID to avoid stale queue reference

E2E tests for all ACs (tests/e2e/followup-acs.spec.ts):
- AC-F1: Drag reorder (4 tests)
- AC-F2: ReasonPrompt integration (7 tests)
- AC-F5: Staleness visualization (3 tests)
- AC-F6: Batch mode (2 tests)
- AC-F7: SyncStatus (2 tests)
- ReasonPrompt behavior (3 tests)

Tests: 388 frontend + 119 Rust + 32 E2E all passing

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

src-tauri/src/data/lore.rs

@@ -11,13 +11,12 @@ use mockall::automock;
 /// Trait for interacting with lore CLI
 ///
 /// This abstraction allows us to mock lore in tests.
+/// Note: We don't use `lore health` because it's too strict (checks schema
+/// migrations, index freshness, etc). MC only cares if we can get data.
 #[cfg_attr(test, automock)]
 pub trait LoreCli: Send + Sync {
     /// Execute `lore --robot me` and return the parsed result
     fn get_me(&self) -> Result<LoreMeResponse, LoreError>;
-
-    /// Execute `lore --robot health` and check if lore is healthy
-    fn health_check(&self) -> Result<bool, LoreError>;
 }
 
 /// Real implementation that shells out to lore CLI
@@ -39,15 +38,6 @@ impl LoreCli for RealLoreCli {
         let stdout = String::from_utf8_lossy(&output.stdout);
         serde_json::from_str(&stdout).map_err(|e| LoreError::ParseFailed(e.to_string()))
     }
-
-    fn health_check(&self) -> Result<bool, LoreError> {
-        let output = Command::new("lore")
-            .args(["health", "--json"])
-            .output()
-            .map_err(|e| LoreError::ExecutionFailed(e.to_string()))?;
-
-        Ok(output.status.success())
-    }
 }
 
 /// Errors that can occur when interacting with lore
@@ -287,15 +277,6 @@ mod tests {
         assert_eq!(result.data.open_issues[0].iid, 42);
     }
 
-    #[test]
-    fn test_mock_lore_cli_health_check() {
-        let mut mock = MockLoreCli::new();
-
-        mock.expect_health_check().times(1).returning(|| Ok(true));
-
-        assert!(mock.health_check().unwrap());
-    }
-
     #[test]
     fn test_mock_lore_cli_can_return_error() {
         let mut mock = MockLoreCli::new();