Fix packaging of design-time providers referenced via ProjectReference

[T-Gro]

Packing an F# library that activates a design-time type provider via a ProjectReference marked IsFSharpDesignTimeProvider="true" stopped including the provider assembly in the package (regressed by #18929).

dotnet pack collects per-framework content in an inner build with BuildProjectReferences=false, where @(_ResolvedProjectReferencePaths) is empty, so the old AfterTargets="ResolveReferences" form of PackageFSharpDesignTimeTools produced nothing. Registration of the content target moves back to evaluation time, and the target now resolves each provider through the SDK's own nearest-target-framework negotiation (GetTargetFrameworks -> GetReferenceNearestTargetFrameworkTask -> GetTargetPath). No reference build is triggered, so pack --no-build works (#12320) and ResolveReferences is not forced (#18924 stays fixed).

The provider is packaged under its own resolved target-framework folder — the moniker the compiler's design-time load actually probes for (src/Compiler/Facilities/CompilerLocation.fs), which is not necessarily the consumer's TargetFramework. The whole provider output travels with its subfolder layout preserved (culture satellites under <culture>/, native under runtimes/<rid>/...), so nothing is lost or collides on a shared file name; the consumer's own FSharp.Core / System.ValueTuple (and FSharp.Core's satellites) are excluded. A gesture that resolves to nothing, or to an output that was not built, fails loud instead of silently dropping.

The standard gesture now packages the provider on its own, so consumers no longer need a hand-written TargetsForTfmSpecificContentInPackage workaround.

[github-actions]

✅ No release notes required

[github-actions]

🔍 Tooling Safety Check — Affects-Build-Infra, Affects-Design-Time, Affects-Test-Tooling
Affects-Build-Infra: modifies Microsoft.FSharp.NetSdk.targets
Affects-Design-Time: changes design-time provider packaging resolution
Affects-Test-Tooling: end-to-end build test scripts spawn external processes

Generated by PR Tooling Safety Check · opus46 5.7M · ◷

[T-Gro]

🤖 This review was generated by AI (@expert-reviewer agent). Findings may contain inaccuracies — please verify independently.

Nice, well-documented fix — the move to eval-time registration plus GetTargetFrameworks/GetReferenceNearestTargetFrameworkTask/GetTargetPath correctly avoids forcing ResolveReferences and keeps pack --no-build working, and the two fail-loud <Error> guards are a real improvement over the previous silent drop. Two robustness observations on the framework-folder derivation and the flattening glob; both are non-blocking.