Reenable sdk->runtime subscription for ApiCompat task

[akoeplinger]

In #94292 the ApiCompat version bump ran into an issue with source build.
We temporarily reverted the bump and disabled the subscription 736b3d22-d45c-4c36-de26-08db63374d9b.

This issue tracks reenabling that.

/cc @ViktorHofer

[ghost]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In #94292 the ApiCompat version bump ran into an issue with source build.
We temporarily reverted the bump and disabled the subscription 736b3d22-d45c-4c36-de26-08db63374d9b.

This issue tracks reenabling that.

Author:	akoeplinger
Assignees:	-
Labels:	area-Infrastructure
Milestone:	9.0.0

[ViktorHofer]

Ongoing discussion from #94292 (comment):

That sounds like a design mismatch. Source built msbuild task packages target net9.0 when building from source which can't be executed in our portable source build leg. Shouldn't this source build leg always target a nightly SDK to avoid such a major version mismatch?

It does. In theory it's not limited to source build, right? A dependent package could have been changed from targeting net8.0 to producing net9.0 exclusively and that would cause the same issue in the other non-source-build legs. Such a scenario probably would never occur I assume.
/cc @MichaelSimons

We try to avoid that in a non source build environment by making people use properties like NetToolMinimum and NetToolCurrent. Not saying that this issue hasn't happened before but probably only rarely. The solution to that is usually just to revert the TFM upgrade in a specific component until repositories consume a newer SDK.
We can't really do that in source build as it requires us to target the latest version of .NETCoreApp, even for build tasks.

cc @MichaelSimons for opinions on this

[ViktorHofer]

Re-enabled.