fix(git): recover untrusted repository operations with a confirmation flow

[guantw]

Summary

Recovery flow for Git dubious-ownership / untrusted repositories: blocked operations now surface a unified trust confirmation instead of failing with no exit, and the original command completes once the repository root is authorized.

• Detect dubious ownership at the service boundary and raise typed trust errors instead of raw failures.
• Confirm the repository root through a unified interactive flow that writes safe.directory and replays the blocked operation once.
• Keep trust probes read-only and non-interactive paths prompt-free; never replay side-effecting commands.
• Provide an authorization entry on the Git scene trust-required state and localized manual-resolution copy for uncertain or unsupported outcomes.
• Serialize Deep Review target Git reads so one interactive trust decision settles before sibling bounded-evidence requests.
• Normalize trust prompt dedupe keys per platform (Windows/UNC case-fold, POSIX case-safe) and scope read-only graph queries to non-interactive mode.
• Tighten path identity and scope checks on Windows and harden refresh lifecycle after disposal.

Problem

On Windows, transferring a repository folder to a different account (e.g. system) makes Git refuse to open it with "detected dubious ownership" unless the root is listed in safe.directory. BitFun's Git tooling then failed at the operation boundary, and the Git scene showed a static "trust required" state with no authorization entry. Operations that could not reach any interactive Git call ? such as Deep Review target preparation ? stayed blocked, and a second attempt was required even after the user approved the trust prompt.

Analysis

• libgit2 and the Git CLI each validate repository ownership and reject access when the process user differs from the repository owner; the only sanctioned relief is safe.directory, which BitFun never wrote.
• Failures surfaced as unstructured command errors, so callers could not distinguish "needs trust" from a broken repository, and no UI offered a path to authorize.
• Concurrent read-only requests raced on the trust decision: one request opened the prompt while a sibling completed a read-only confirmation probe and failed fast with trust unsupported, aborting the whole preparation even after the user approved.
• The fix treats trust as a typed, recoverable interruption: the service classifies owner rejection, an interactive coordinator writes the exact canonical root and replays the blocked command once, probes stay read-only and never write configuration, and non-interactive paths remain prompt-free.

Verification

• Frontend: git/trust suites pass (GitAPI, GitTrustPromptService, GitTrustPromptRenderer, GitTrustOutcomePresenter, GitStateManager, DeepReviewService, WelcomePanel).
• Rust: services-integrations git tests (29) and remote_workspace_policy contract tests pass.
• macOS /var -> /private/var symlink case covered by keeping repository-root discovery path-stable; confirmed green on macOS/Ubuntu CI.

Reviewer Notes

• Trust probes never write Git configuration and never replay side-effecting commands; the replayed command is the original operation after explicit consent.
• Deep Review target reads are serialized so a single interactive trust decision settles before sibling requests can fail fast.