fix(kanban): preserve worktree repository bindings

[rhon3n]

Summary

Fixes a recurring Kanban failure where auto-decomposed worktree tasks were persisted without any repository binding, then entered spawn_failed / gave_up loops when the board intentionally had no default_workdir.

• propagates a resolvable common-repository binding to decomposed worktree children
• rejects unresolved worktree tasks before persistence or claim
• preserves task-specific worktree isolation
• does not synthesize a board-wide default
• documents that linked-worktree inheritance supplies a repository binding, not commit inheritance

Reproduction

A valid root task used an explicit linked-worktree path on a multi-project board with no default repository. Auto-decomposition created children with:

workspace_kind=worktree
workspace_path=NULL
project_id=NULL

Each promoted child failed before its worker process started.

Tests

python -m pytest -q \
  tests/hermes_cli/test_kanban_cli.py \
  tests/hermes_cli/test_kanban_decompose_db.py \
  tests/hermes_cli/test_kanban_project_link.py \
  tests/hermes_cli/test_kanban_worktree_isolation.py \
  tests/plugins/test_kanban_dashboard_plugin.py

55 passed, 1 existing Starlette deprecation warning
git diff --check: pass

Safety

• no board default is inferred or written
• malformed decomposition is rejected atomically
• existing project-bound and board-default-bound resolution remains supported
• no live board SQLite mutation is part of the implementation

[Enough1122]

AI code review — automated review for reference; please use your judgment.

This is the right fix for the decompose-provenance hole: storing the common repository root as each child's binding (instead of NULL + board-default guesswork at dispatch) makes sibling checkouts deterministic and independent of whatever the gateway's CWD is, inheriting project_id closes the "children lose the repo link" gap, and fail-fast validation with a three-part diagnosis beats silent misbinding every time. The tests are unusually good — real git fixtures proving children branch from repo HEAD rather than a sibling's dirty worktree, plus an atomicity test showing a rejected legacy root leaves zero rows behind. Points:

1. hermes_cli/kanban_db.py:_common_repo_root_for_workspace (~7791) — the .git-basename heuristic only recognizes standard non-bare hosts. For worktrees of a bare repo (common dir like /srv/git/app.git, name ≠ ".git"), the function falls through to the parent-walking fallback, which can't find a working tree from inside a linked worktree → binding unresolved → such tasks now either degrade to board-default or get rejected outright by the new validator. Suggest treating common_dir itself as the repository root whenever it isn't equal to git_dir (it IS the repo in that layout), regardless of its basename.
2. kanban_db.py:create_task — deferred-binding workflows are gone: previously one could create a worktree task unbound and patch workspace_path before dispatch; now creation fails immediately. That's the correct default, but any script/bot using create-then-bind will start failing at the create step. Worth an explicit migration note in the changelog alongside the doc update.
3. kanban_db.py:_project_repository — bare except Exception: return None hides broken project links (deleted project, wrong db path); a debug log before returning would make the resulting "" validator message traceable to its cause. (nit)
4. Semantics worth documenting once more in the docs hunk: children of a linked-worktree root now base on the repo's current default HEAD, not the root task's branch tip. The test pins this deliberately (child_head == repo_head != sibling_head), but a user expecting subtasks to build on the root's in-flight commits will be surprised — a sentence in the kanban.md section you touched would preempt that. (nit)

No blocking issues found.