fix: bound leadership dashboard filtering

.project-docs/30-worklog/tasks/20260902-kanban-filter-7e3a91c4.md

@@ -0,0 +1,65 @@
+# Task: Fix kanban table filters
+
+## Identity
+
+- Task ID: 20260902-kanban-filter-7e3a91c4
+- Mode: Feature
+- Branch: main
+- Worktree: /Users/inmanx/Documents/lwltAPI
+- Base commit: d034f649c4e7c5d0856f22053b92d2e5a63be5eb
+- Owner: codex
+- Status: Ready for integration
+
+## Scope
+
+- Repair leadership-dashboard table filtering when a business type and/or keyword is submitted.
+- Remove redundant full-range hydration and connection amplification from both ordinary loads and keyword queries.
+- Bound database work and propagate HTTP disconnects into the dashboard read pipeline.
+- Change the dashboard's frontend, API, and service default page size to 20 rows.
+- Add explicit in-flight and timeout feedback plus focused regression coverage.
+
+## Intent And Constraints
+
+- Preserve the existing read-only leadership authorization, date/actor/status semantics, historical business-type inference, and business-facing result projection.
+- Keep full-fidelity task output for rows returned on the current page while using lean candidate projections for filtering and aggregation.
+- Do not modify ERP behavior, task lifecycle state, permissions, runtime services, deployment, or canonical project memory in this Feature task.
+- Coordinate around the ready-for-integration dashboard-metrics task: its display-only summary-card semantics are independent of this filter-form/API repair, although both touch focused dashboard regression files.
+- Do not read `.env`, restart the running service, or perform external writes without separate user authorization.
+
+## Outcome
+
+- Reproduced the reported failure in the already authenticated local dashboard: submitting the form sent the expected `from`, `to`, `status`, `business_route_id`, `search`, `limit`, and `offset` parameters, but the request exceeded the 15-second client deadline and was aborted while unrelated health and task-list requests remained responsive.
+- Confirmed from privacy-safe request diagnostics that dashboard requests alone were accumulating without completion while health, readiness, and task-list endpoints remained responsive. The old implementation could use multiple pool connections per request, hydrate the same candidates repeatedly, and continue database work after the browser's 15-second timeout.
+- Pushed the selected business type into candidate SQL while retaining null-route legacy rows for instruction/operation inference.
+- Replaced pool-level parallel reads with one read-only transaction per dashboard request. The transaction uses one checked-out connection, a 5-second PostgreSQL statement timeout, and a 9-second service query budget.
+- Propagated request/reply disconnects through an `AbortSignal`, stopping all subsequent query and projection stages when the client has gone away. Active database statements remain bounded by the server-side timeout.
+- Removed the ordinary-load classification requery and the keyword path's candidate rehydration query. Ordinary loads fetch encrypted original text only for legacy null-route candidates; keyword loads use the lean persisted receipt/error projection and load historical messages only for relevant candidates not already matched by task fields.
+- Kept full-fidelity detail hydration after pagination and reduced that page from 50 to 20 rows consistently in the browser, API schema, and service fallback.
+- Added privacy-safe per-stage and aggregate dashboard timing/count diagnostics without recording filter values or business content.
+- Added explicit filter-form busy state, disabled the query button during an in-flight request, exposed actionable client and server timeout messages, and advanced the JavaScript cache token.
+- Added a focused regression that protects single-connection read-only execution, database and request bounds, business prefiltering, reduced keyword hydration, page-only detail hydration, 20-row defaults, form busy state, and timeout feedback.
+- Preserved read-only dashboard authorization, historical business-type inference, result/status classification, task pagination, and ERP/task lifecycle behavior.
+
+## Verification
+
+- Passed: `git diff --check`.
+- Passed: `node --check LianSyn-platform/app.js`.
+- Passed: focused dashboard regression, 5/5 tests.
+- Passed: `node --run check` (TypeScript no-emit check).
+- Passed: `node --run test:control-plane`, 156/156 tests.
+- Passed: `node --run check:repo`, 10/10 tests.
+- Passed: `node --run test:legacy`, 265/265 tests.
+- Passed: `node --run build`.
+- Runtime post-change verification was not run because the currently running control-plane process must be restarted to load the TypeScript change, and restart requires separate user authorization.
+
+## Follow-ups
+
+- During integration, reconcile the focused dashboard test, `app.js`, `index.html`, and cache token with ready task `20260902-dashboard-metrics-static-a91c`; its display-only metric-card behavior is semantically independent and should be preserved.
+- After integration and an explicitly authorized service restart, repeat the captured business-type-plus-keyword query and verify it completes before the client deadline with a filtered total and matching table rows.
+
+## Promotion Candidates
+
+- Target canonical document: `.project-docs/10-architecture/data-flow.md` during Integration Gate review.
+- Proposal: document the leadership-dashboard list as a bounded single-connection read pipeline—SQL prefilter and lean candidate projection, historical-message hydration only for unmatched search candidates, then full projection only for the paginated result rows.
+- Evidence: browser network reproduction, privacy-safe server request diagnostics, focused regression, statement/request resource guards, and the full repository verification recorded above.
+- Semantic conflicts: none with AUTH-001, the business-facing dashboard projection, or the concurrent display-only summary-card task.