In a linked worktree .git is a file pointing at <main>/.git/worktrees/<name>, and that directory has a commondir file pointing back to the main .git where refs and objects actually live. go-git's PlainOpen roots its storer at the per-worktree dir, which has no objects/ and no refs/heads/, so even resolving HEAD fails with reference not found.

go-git has PlainOpenOptions.EnableDotGitCommonDir for this, but in v5 it opens commondir without closing it, which on Windows blocks t.TempDir() cleanup and would leak an fd per open in any long-running caller. The fix is on go-git's main but not in any v5 tag including v5.19.0.

We already shell out to git rev-parse --git-common-dir for DatabasePath(), and #194 already rebuilds the storage to set AlternatesFS, so this wraps the dotgit fs in dotgit.NewRepositoryFilesystem with the common dir during that same rebuild. go-git never opens commondir itself.

This is separate from #194. That one is about objects/info/alternates (git clone --shared / --reference), which is a different mechanism with the same error message. The two compose: a worktree of a --shared clone needs both, and the RepositoryFilesystem wrapper routes objects/info/alternates to the common dir where it lives.

Extended the existing worktree test to actually read refs and objects rather than just checking path resolution.

Fixes #195