fix(kanban): propagate deferred scratch-workspace sweep to grandparents

[r266-tech]

Follow-up to #41352 (deferred parent scratch-workspace cleanup).

_try_cleanup_parent_workspaces() sweeps a deferred parent scratch dir once all its children are terminal, but the sweep was non-recursive. In a depth-3+ scratch decomposition chain A->B->C, B's completion defers (C still active), and when leaf C completes it sweeps only its direct parent B and stops — A's scratch dir leaks on disk forever, with no global workspace GC to reclaim it (the only rmtree sites are own-scratch and direct-parent). It accumulates across runs.

Fix: after handling each eligible parent, recurse _try_cleanup_parent_workspaces(conn, parent_id, _visited) so the sweep cascades up the whole chain. The task DAG is acyclic (_would_cycle), and a threaded _visited set bounds each ancestor to one evaluation per completion cascade so diamond-shaped DAGs aren't re-traversed per path. The optional _visited keeps the existing 2-arg callers unchanged.

Adds depth-3 chain and diamond-DAG regression tests (existing tests only covered 2-level chains).

If this already landed via a separate patch, feel free to close.

[teknium1]

Thanks for the focused follow-up. The premise remains valid on current main: hermes_cli/kanban_db.py:4545 evaluates only direct parents, while _cleanup_workspace() defers deletion for active children at hermes_cli/kanban_db.py:4499-4515. The existing regression coverage at tests/hermes_cli/test_kanban_db.py:2600-2678 covers only the one-level case.

The proposed recursive traversal is bounded by _visited, follows the existing terminal-child predicate, and the depth-3 plus diamond tests directly exercise the missing cases. GitHub reports the PR as mergeable against current main; salvage should be mechanical despite unrelated movement in these files.

Automated hermes-sweeper review.