Test cross-project Kanban functionality

**GIT COMMIT BLOCKED - PERMISSION ISSUE** The implementation is complete but cannot be committed to git due to a Docker container permission issue. **Problem:** - The `.git` directory is owned by `root` - The `claude` user cannot write to `/rails/.git/index.lock` - Additionally, test files could not be created due to file permission issues **Current State:** - Code changes exist in working directory (see git status) - Code diffs are already attached to this ticket via the API - Test files were created in `/tmp/` and need manual placement - Ticket is in `pending_audit` status awaiting review **Required Action:** Git commit and PR creation needs to be done by a user with proper permissions. Test files need to be manually copied from `/tmp/` to their proper locations.

Created comprehensive tests for cross-project Kanban functionality: 1. Unit Tests (dashboard_controller_spec.rb): - Tests for all_projects=true parameter handling - Tests for project_id parameter handling - Tests for archived projects exclusion - Tests for project associations loading - Tests for empty states 2. Integration Tests (kanban_cross_project_spec.rb): - Tests for single project view - Tests for all projects view - Tests for project switching functionality - Tests for project selector dropdown - Tests for project badge display on cards - Tests for proper column organization across projects - Tests for empty states - Tests for priority indicators and agent display 3. Performance Tests (kanban_performance_spec.rb): - Query count tests for single and all-projects modes - N+1 query prevention tests - Scalability tests with many tickets - Database index usage verification - Memory usage tests NOTE: All test files need to be manually copied from /tmp/ to their respective locations due to file permission issues.

**WORKFLOW CORRECTION NOTE:** This ticket was moved to `blocked` status because it was incorrectly moved to `in_progress` when work had not actually started. The Tinker system does not have a "todo" state. The closest equivalent to "ready but not started" is the `blocked` state, which prevents the ticket from being claimed until it's truly ready for implementation. **When this ticket is ready for implementation:** - A Worker should use `transition_ticket` with event `start_work` to move it to `in_progress` and claim it **Current status:** Ready for prioritization/assignment, but not actively being worked on.