### Problem When filtering work items by status, the filter incorrectly includes items that would actually display a different status due to active status mappings. ### Example Scenario 1. Item has `system_defined_status_id = 1` (system "to do" status) 2. Custom status "To Do" exists with `converted_from_system_defined_status_identifier = 1` 3. Status mapping exists: "To Do" → "In Progress" for task work item type 4. Item is a task, so it displays as "In Progress" in the UI 5. **Bug**: Item appears in filter results when filtering by "To Do" status ### Expected Behavior Items should only appear in filter results if their **resolved status** (after applying mappings) matches the filter criteria. ### Current Behavior Items appear in filter results if their **raw status data** matches the filter criteria, ignoring status mappings. ### Impact - Users see incorrect items in filtered lists - Status-based workflows become unreliable - Confusion between what users see in the UI vs. filter results ### Acceptance Criteria - [ ] Items mapped away from the filtered status are excluded from results - [ ] Items that map TO the filtered status are included in results (existing behavior) - [ ] Time-constrained mappings are respected - [ ] Both custom and system-defined statuses work correctly - [ ] Different work item types are handled appropriately (mappings are type-specific)