[5.x]: Adding a site makes `craft up` rewrite project.yaml with a new dateModified

[jeroenlammerts]

What happened?

Description

After adding a new site to project config, running php craft up on a database that
doesn't have that site yet rewrites config/project/project.yaml with a new
dateModified. Nothing else changes, so the deploy that brings the site in leaves you with
a dirty working tree:

-dateModified: 1750000000
+dateModified: 1750086400

Stores::afterSaveCraftSiteHandler() runs during the apply, because Craft fires
Sites::EVENT_AFTER_SAVE_SITE from its own project config handler. It checks the
commerce_sitestores table, which the apply hasn't filled in yet, and writes the mapping
itself via $projectConfig->set() — bumping dateModified, even though the incoming YAML
already has the mapping. It also points the site at the primary store rather than the one
in the YAML; the apply corrects that afterwards.

ProductTypes::afterSaveSiteHandler() guards against this with
!$projectConfig->getIsApplyingExternalChanges(). Stores doesn't. Setting
allowAdminChanges: false makes no difference, since migrate/all sets readOnly = false
for the rest of the run.

Steps to reproduce

1. Any install with Commerce.
2. Add a new site and commit config/project/.
3. On a database that doesn't have that site yet, pull and run php craft up.
4. git status.

One new site is enough; it fires once per site that's new to the database.

Expected behavior

config/project/ is unchanged after the apply.

Actual behavior

project.yaml has a new dateModified.

Craft CMS version

5.10.13.2

Craft Commerce version

5.7.1

PHP version

No response

Operating system and version

No response

Database type and version

No response

Image driver and version

No response

Installed plugins and versions

[linear-code]

COM-600