[release/10.0] Do not store result of cast in IDynIntfCastable scenarios

[github-actions]

Backport of #125605 to release/10.0

/cc @MichalStrehovsky

Customer Impact

• Customer reported
• Found internally

Hit by the Windows team in #125577. CsWinRT previously didn't use IDynamicInterfaceCastable for casting much. In 3.0, it's going to fully lean into it and this will be a problem.

Regression

• Yes
• No

Regressed in .NET 9.0 in #108328 where we were fixing a different caching issue and introduced a new bug ("I also fixed the other checks for consistency" in the PR - these were all bugs).

Testing

This was missed because it's a caching issue. We need to cache a result and then return wrong result from the cache on a subsequent type check that should behave differently. We now have a test specifically exercising the cache.

Risk

This is low risk, we're adding a condition for caching and the condition is scoped to just the bug scenario.

IMPORTANT: If this backport is for a servicing release, please verify that:

• For .NET 8 and .NET 9: The PR target branch is release/X.0-staging, not release/X.0.
• For .NET 10+: The PR target branch is release/X.0 (no -staging suffix).

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib
See info in area-owners.md if you want to be subscribed.