Player libraries are code signed with bespoke entitlements

Steps to reproduce:

1. Build any project as a macOS Standalone player (IL2CPP or CoreCLR scripting backend)
2. In Terminal, run: codesign -d --entitlements - --xml "<Build>.app/Contents/Frameworks/UnityPlayer.dylib"
3. Run: codesign -dv "<Build>.app/Contents/Frameworks/UnityPlayer.dylib" (and on other dylib files)

Actual results:
The libraries carry Unity's Developer ID signature with the hardened runtime flag and these entitlements:

• com.apple.security.cs.disable-library-validation
• com.apple.security.cs.disable-executable-page-protection

Expected results:
Libraries are signed without entitlements. Entitlements only take effect on an application's main executable.

Reproducible with versions: 6000.5.0b3+, 6000.6.x, 6000.7.x, 7000.0.0a9
Not reproducible with versions: 6000.5.0b2 and 6000.4
Tested on (OS): macOS

Notes:

• macOS reads entitlements only from a process's main executable, so in a standard application bundle these entries do not change how the game runs. They do ship in the built game, and signing tools that preserve existing entitlements when re-signing (for example rcodesign) copy them into the developer's own signature.
• macOS Dedicated Server builds: the server executable keeps Unity's signature, so these entitlements apply to the running server process.

Workaround:
Replace the existing signatures on the libraries in Contents/Frameworks when re-signing the application: sign each library with codesign -force and no -entitlements option, or remove the signatures first (codesign --remove-signature) when using another signing tool.