See #1362 for context on the platform manifest, and how the official build currently harvests every platform's artifacts from CoreCLR and Libraries to build full platform manifests.

Local builds (such as source-build) only have access to a single machine/platform, so harvesting is not possible. Without harvesting, the platform manifest ends up incomplete and can cause problems, in particular causing dotnet publish to include libraries that contradict the ones already included in the target platform's shared framework.

The idea I've been considering so far is a template approach. (Copying from #1362):

I think we need to stop using harvesting to populate this file, and instead calculate the contents. We probably need to keep a platform manifest template (list of files) in the source to act as a template.

This would normally be a maintenance hazard, but we can prevent that:

1. Each platform uses the template to generate an expected platform manifest, which is used when building targeting packs, runtime packs, installers, etc.
2. When running a platform-specific job, validate:
   • All sharedfx files generated on that platform are in the manifest template.
   • There are no files in the template that are expected to be built on the current platform but weren't.
3. By the time any CI/PR validation build ends, all platforms have run the validation step. This means that if all jobs succeed, we know the platform manifest is valid. Even if some platforms silently produced bad platform manifests, the build would fail overall.
4. Since official builds stop if some jobs failed, there is no risk of releasing an outdated platform manifest.

This does impact dev flows. Someone may add a new file to the shared framework and not know how to properly update the manifest template. To mitigate this, when the validation step fails, it should emit the corrected list of files and tell devs where they need to put it to fix up their PR.