fix(yield): group attribution by canonical repo root, not path string

[ozymandiashh]

Closes #713.

Problem

The single-owner attribution from #692 enforces "one commit, one owner" per launch-directory string: repo groups are keyed by the raw projectPath while getCommitsInRange runs git log --all with no pathspec. Sessions launched from two subdirectories of one monorepo (or from linked worktrees) form independent groups that each pull the identical repo-wide history, and the same commit is credited once per group - one commit, two productive sessions, commitCount 2. Repro details in the issue; every pre-existing test stayed green because each used a single path per repo.

Fix

• Repo groups key on the canonical root (git rev-parse --show-toplevel), resolved once per path and cached.
• Linked worktrees unify via --git-common-dir, both sides realpath-canonicalized before comparison (symlinks, platform case-insensitivity). If git or realpath fails, the session degrades to the existing cwd fallback; a comment documents the accepted residual for a main repo moved after git worktree add (git's own metadata is stale in that state).
• Non-git and missing paths keep the current behavior.

Verification

• New regression: two sessions from two subdirectories of one temp repo, one commit inside both windows -> exactly one productive owner, the other lost-candidacy, commitCount 1. Pre-fix run on the base recorded both sessions productive.
• New linked-worktree regression, same shape. Both tests are mutation-checked: removing the canonical grouping (or the common-dir merge lookup) makes them fail with the exact yield: single-owner attribution double-credits commits across monorepo subdirs and worktrees (groups keyed by path string, not repo root) #713 symptom.
• npx tsc --noEmit clean; yield suites 8/8.

[iamtoruk]

Apologies — this collided with a maintainer-side fix (#719) that was developed in parallel straight off your issue writeup, before we saw this PR; entirely our process miss for not checking the issue's linked PRs first. #719 landed on the same design you proposed (canonical grouping, worktrees unified via realpath'd common-dir, separate repos guarded), so the bug itself is fixed on main.

Two details in yours look potentially additive over #719: the explicit platform case-insensitivity handling in the canonical comparison, and the documented residual for a main repo moved after git worktree add. If either isn't fully covered by #719's realpath canonicalization, a focused follow-up PR for the delta would be very welcome — and either way, thank you for both the sharpest bug report this repo has received and a complete fix to go with it.