v0.17.0

feat(git): support reftable repos via CLI ref resolution (#451) (#452)

Fixes #451 , and goes further than the first commit: sem now **works**
on reftable repos instead of erroring clearly.

## Approach
libgit2 can't read reftable refs, but reftable changes nothing else ,
the object DB and index are standard. So:
- tolerate `extensions.refstorage` (registered alongside
`relativeworktrees`, one place);
- detect it per-repo (`cli_refs` flag on GitBridge);
- route **only ref resolution** through the git CLI (`git rev-parse
--verify`), via one `cli_rev_parse` helper and four thin wrappers
(`resolve_object`, `head_commit`, `has_head`, `revwalk_from_head`)
swapped into the 12 ref-touching call sites;
- everything downstream (trees, blobs, diffs, revwalks) stays libgit2,
addressed by OID.

Same pattern as the existing sparse-checkout CLI fallback.

## Probed before building
With the extension registered, libgit2 empirically: opens the repo ✅,
reads objects/trees/blobs by OID ✅, walks revs from a pushed OID ✅, and
**fails loudly** (InvalidSpec) on every ref-touching call ✅ , so a
missed path produces an error, never a silently wrong answer.

## Verified
- New end-to-end test on a **real** reftable repo (git 2.55): HEAD sha
identical to `git rev-parse`, working diff with correct before/after
contents, `HEAD~1..HEAD` range diff, per-file history walk. Skips
gracefully when git predates reftable (2.45).
- `sem diff` and `sem blame` verified via the release binary on a real
reftable repo.
- sem-core: 412 passed, 0 failed.

## Residual gap (documented)
The cache freshness oracle's direct `git2::Repository::open` is
`.ok()`-guarded , on reftable repos it skips the acceleration;
correctness unaffected. Ref lookups need `git` on PATH (already required
by blame/log paths).

Thanks @bengry for the report and clean repro.