Fix equity dotted-ticker fallback in SymbolCache - #9812

Description

Restricts SymbolCache's dotted-ticker fallback to SecurityType.Base symbols and adds regression coverage verifying that an Equity key such as LIFE.1 cannot satisfy a missing exact LIFE lookup.

Related Issue

Fixes #9781

Motivation and Context

The dotted-ticker fallback was introduced for custom-data aliases such as BTC.Bitcoin -> BTC. Applying the same fallback to Equity symbols made resolution depend on registration order: caching LIFE.1 first could cause a later lookup for LIFE to return the wrong security identity. Limiting the fallback to Base/custom-data symbols preserves its intended compatibility behavior without allowing an equity permtick to shadow a distinct ticker.

Requires Documentation Change

No. This corrects internal symbol-cache lookup behavior without changing a public API.

How Has This Been Tested?

• Reproduced the pre-fix production behavior with a focused driver: a LIFE lookup incorrectly returned the cached LIFE.1 Equity.
• Verified the post-fix production behavior with the same driver: the Equity fallback is rejected and the Base/custom-data fallback remains available.
• Compiled Tests/QuantConnect.Tests.csproj successfully with the pinned .NET 10 SDK container (zero compile errors).
• Verified the two changed files with dotnet format whitespace --verify-no-changes and git diff --check.
• Attempted the focused NUnit test in the lightweight SDK container. The test host was aborted before the selected assertion because the test assembly unconditionally initializes Python.NET and the container lacks LEAN's foundation Python runtime (GIL must always be released). Therefore, this does not claim that the focused NUnit test passed locally; the repository's official environment and complete matrix are left to GitHub CI.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed. (Pending GitHub CI; see the local environment limitation above.)
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>.

AI-assisted implementation and independent review were used. I reviewed the complete diff and remain responsible for the contribution.