Fix git-crypt in linked worktrees (per-worktree fallback)

[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 per-worktree when it is already provisioned, and otherwise fall back to git rev-parse --git-common-dir:

• Main worktree: unchanged (per-worktree dir == common dir).
• Linked worktree with no local state: falls back to the shared key, so a fresh
  git worktree add checks out decrypted.
• Linked worktree with its own provisioned state: keeps using it.

Because the per-worktree location still wins when present, this composes with
setups that keep the git-crypt filter config per-worktree
(extensions.worktreeConfig), giving independent per-worktree lock state
without duplicating the key.

---

This is the minimal, shared-key approach. See companion #334 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