Fixes terminal commit links in multi-repository workspaces

[qianxunslimg]

Description

Problem

In workspaces with multiple Git repositories, such as projects with nested repositories or submodules, terminal commit links can fail to resolve through GitLens.

When this happens, commit SHAs printed in terminal output are not handled by GitLens and VS Code can fall back to other link providers, such as file search results.

Root Cause

GitTerminalLinkProvider currently relies on container.git.highlander to determine the repository for terminal links. In multi-repository workspaces, highlander is undefined, so terminal links cannot be created even when the terminal has a clear working directory.

Commit SHA links are also validated asynchronously before being returned. If that validation is cancelled, a valid commit SHA can be dropped before GitLens creates a terminal link.

Fix

This change resolves the repository for terminal links by:

• keeping the existing highlander behavior when there is a single repository
• falling back to the terminal shell integration cwd via getOrOpenRepository(..., { detectNested: true })
• falling back to the best available repository when no terminal cwd is available

It also creates commit SHA terminal links once a repository path has been resolved, avoiding cancellation-prone validation before returning the link.

Branch, tag, and range link behavior is preserved.

Testing

• pnpm exec eslint src/terminal/linkProvider.ts
• pnpm exec tsc --noEmit --project tsconfig.json
• Manually verified in a workspace with nested repositories/submodules that terminal git log --oneline commit SHAs open through GitLens instead of falling back to VS Code file search.

Checklist

• I have followed the guidelines in the Contributing document
• My changes follow the coding style of this project
• My changes have been formatted and linted
• My changes include any required corresponding changes to the documentation (including CHANGELOG.md and README.md)
• My changes have been rebased and squashed to the minimal number (typically 1) of relevant commits
• My changes build without any errors or warnings
• My changes have a descriptive commit message with a short title, including a Fixes $XXX - or Closes #XXX - prefix to auto-close the issue that your PR addresses