Modify dashboard controller to support showing all projects

**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` - Error: `fatal: Unable to create '/rails/.git/index.lock': Permission denied` **Current State:** - Code changes exist in working directory: - `app/controllers/dashboard_controller.rb` (modified) - `app/views/dashboard/kanban.html.haml` (modified) - `app/views/tickets/_kanban_card.html.haml` (modified) - Code diffs are already attached to this ticket via the API - Ticket is in `pending_audit` status awaiting review **Required Action:** The git commit and PR creation needs to be done by a user with proper permissions: 1. Commit the changes with message describing cross-project Kanban functionality 2. Push to remote repository 3. Create pull request 4. Update tickets 35-38 with the PR URL **Files Modified (committed via code_diff API):** - Dashboard controller now supports `all_projects=true` parameter - Kanban view includes project selector dropdown - Kanban cards display project badges in all-projects mode

Implemented the all_projects mode in the kanban action: - Added `@all_projects_mode` flag that checks for `all_projects=true` parameter - When true, fetches tickets from all active projects using `Project.active.all` - Includes project association with tickets to avoid N+1 queries - Sets `@project` to nil in all-projects mode - Preserves existing single-project functionality The implementation: 1. Checks params[:all_projects] and converts to boolean 2. In all-projects mode: fetches from all active projects, excludes archived projects 3. In single-project mode: works as before with project_id parameter 4. Eager loads project, assigned_agent, and subtasks associations for efficiency

**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.