Fix git-crypt in linked worktrees (shared key via --git-common-dir)

[thebino]

Running git worktree add inside a git-crypt repository fails in the smudge filter:

git-crypt: Error: Unable to open key file - have you unlocked/initialized this repository yet?
error: external filter '"git-crypt" smudge' failed
fatal: <file>: smudge filter git-crypt failed

git-crypt resolves its internal state directory (.git/git-crypt, which holds the symmetric keys) from git rev-parse --git-dir. In a linked worktree that returns .git/worktrees/<name>, which never contains the keys — they only ever live in the shared common dir. So checkout of an encrypted file in the new worktree aborts.

---

This PR resolves the state directory via git rev-parse --git-common-dir instead.
In the main worktree this is identical to --git-dir, so behaviour there is unchanged.
In a linked worktree it points at the shared git directory where the keys live, so checkout, lock and unlock all work transparently.

---

This is the minimal, shared-key approach. See companion #333 for a variant that preserves per-worktree lock state via a fallback. They touch the same function and are mutually exclusive — pick whichever fits.

Fixes #105