Add native reftable repository support

[svarlamov]

Part 2 of 2 in the reftable support stack; depends on the async ingestion prerequisite.

Summary:

• decode Git reftable v1/v2 refs and logs natively, with SHA-1/SHA-256, tombstones, compaction races, malformed-input guards, and linked-worktree stacks
• integrate logical update-index cursors without Git spawns and keep checkpoint HEAD lookup independent of reflog history
• complete hash-format-aware root diffs and reuse one TestRepo setup path for files and reftable templates
• cover commits, amend/reset, checkout/switch, stash, revert/cherry-pick, rebase/pull, update-ref, migration, compaction/expiry, linked worktrees, SHA-256 stats, and delayed trace replay end to end

Tests:

• task build
• task fmt
• task lint
• task test TEST_FILTER=reftable
• full task test (all changed-path and reftable coverage passes; four unrelated daemon await timeouts reproduce on origin/main in this environment)

[devin-ai-integration]

Devin Review found 1 new potential issue.

🐛 1 issue in files not directly in the diff

🐛 Starting commit position of one checkout can be overwritten by another checkout's history in reftable repositories (src/daemon/ref_cursor.rs:343-362)

The starting position of the current checkout is picked from every checkout's recorded history at once (refs_at_command_start at src/daemon/ref_cursor.rs:343-362) instead of only the one the command ran in, so a command run in one working copy can be measured against another working copy's position and its changes attributed wrongly.
Impact: In repositories that use the new ref storage and have more than one working copy checked out, commits can be recorded against the wrong starting point, producing missing or incorrect AI/human attribution.

HEAD entries from several worktree stacks collapse onto one "HEAD" map key

RefCursor is per repo family and reftable_entries persists across commands. replace_reftable_stack_entries (src/daemon/ref_cursor.rs:273-289) only clears entries whose path equals the stack it just re-read, so after commands from both the main worktree and a linked worktree the map holds two distinct HEAD keys: head_key(common_git_dir) (materialized from the common stack) and head_key(linked_git_dir) (from .git/worktrees/<name>/reftable).

refs_at_command_start then iterates self.reftable_entries.values() and, for every group whose reference == "HEAD", resolves it with head_position — the offset captured for the current command's worktree — and inserts it under the literal key "HEAD". Because HashMap iteration order is unspecified, whichever HEAD group is visited last wins, so the returned snapshot can carry another worktree's HEAD OID.

The files-backed path does not have this problem: refs_at_reflog_start_offsets (src/daemon/ref_cursor.rs:2672-2695) iterates cmd.reflog_start_offsets, which only ever contains the current worktree's HEAD key.

The new integration test reftable_linked_worktree_uses_its_own_head_log does not exercise this because every command runs in the linked worktree, so common-stack HEAD entries are never materialized (main_worktree stays false and had_common_head stays false).

View 9 additional findings in Devin Review.