Triage bot: give the agent a structured list_tasks filter tool (priority/status/project)

Follow-on to PAR-227 (ANSWER). The bot answered "what high-priority issues still remain for Tesks?" by dumping 8 mostly-Done keyword matches — because its only retrieval tool was search_tasks (full-text), which cannot filter by status or priority. So it couldn't filter by context at all.

Fix: give the agentic loop a structured filter tool and extend the query model to support the two missing dimensions.

• TaskModels.TaskQuery gains priority (Integer) and openOnly (boolean); back-compat constructors preserved so existing callers (MCP/UI) are untouched.
• PostgresTaskSystem.listTasks filters on i.priority = ? and, for openOnly, ws.type not in ('completed','canceled') (a no-status issue still counts as open). Tenant-scoped as before.
• New list_tasks read tool in TriageService.runReadTool: {"tool":"list_tasks","project":"Tesks","priority":2,"open":true} (optional project/assignee/label names, priority 0–4 or name, open, limit). Resolves names→ids, returns compact REF — title (status, priority) rows so the model can both filter via params and reason over the results.
• Prompt: route "what's open / planned / unassigned / high-priority" questions to list_tasks (+ then ANSWER); keep search_tasks for keyword/topic lookup and explicitly tell it search can't filter by status/priority.

So "high-priority issues still open in Tesks" now resolves to list_tasks(project=Tesks, priority=2, open=true) → a grounded conversational ANSWER, not a dump of Done issues.

Tests: new PostgresTaskSystemTest.listTasksFiltersByPriorityAndOpenStatus (priority + open filtering); full backend suite green. Pairs with the now-deployed ANSWER action (PAR-227).