GHSA-fprf-r6rv-xg99

### Summary In Vikunja v2.6.0 the task position recalculation that runs when a saved filter view is created fails open when the requesting user has no accessible projects. Instead of aborting, the search that feeds the recalculation loses its project scope entirely and returns every task in the instance. The server then writes one `task_positions` row per task per view (four views per filter) into views owned by the requesting user, including rows that reference tasks of other tenants the user can never see. Any authenticated user can trigger this. The impact is a cross-tenant integrity violation, a single-request write amplification primitive that scales with instance size, and a violation of the invariant stated in the fix for GHSA-w39f-h553-h2mx that position writes are scoped by project read access. ### Details Vikunja computes kanban and list ordering in a shared `task_positions` table keyed by `(task_id, project_view_id)`. When a saved filter is created, `SavedFilter.Create` (`pkg/models/saved_filters.go:130`) calls `CreateDefaultViewsForProject` (`pkg/models/project_view.go:816`) which, for every default view it creates, calls `RecalculateTaskPositions` with `addExistingTasksToView = true` (`pkg/models/project_view.go:447`). `RecalculateTaskPositions` (`pkg/models/task_position.go:312`) builds a `TaskCollection` and, for filter views (`view.ProjectID < -1`), resets the project scope to zero and injects the saved filter's filter string. The scope of the subsequent search is derived from `getRelevantProjectsFromCollection` (`pkg/models/task_collection.go:188`), which for `ProjectID == 0` returns exactly the projects the requesting user can access. Inside `dbTaskSearcher.Search` (`pkg/models/task_search.go`), the WHERE clause is assembled at line 632: ```go cond := builder.And(builder.Or(projectIDCond, favoritesCond), where, filterCond) ``` `projectIDCond` is only set when `len(opts.projectIDs) > 0` and `favoritesCond` only when the caller opted into the