Unbreak the release build under Xcode 27

[malpern]

The release path fails to build under the newly pinned Xcode 27, before compiling any KeyPath code:

error: unable to open dependencies file
  (.../swift-argument-parser.build/Release/.../ArgumentParserToolInfo-primary.d)

Cause

build-and-sign.sh passes -Xswiftc -no-whole-module-optimization. Xcode 27 makes SwiftPM's newer build system the default, and that build system fails to emit the per-file dependencies output the flag implies. Reproduced deterministically with the script's exact command outside the script.

Why removing the flag is the right fix

It was added in August 2025 as a workaround, commented "disable whole-module optimization to avoid hang". That hang no longer reproduces: a full whole-module release build completes cleanly.

The only way to keep the flag is to also force --build-system native, which Xcode 27 reports as deprecated and slated for removal. So this removes the stale workaround and leaves a comment recording the history, plus that fallback pair if the hang ever returns.

Why nothing caught it

CI builds only Debug and tests. This surfaced on the first real release-candidate build after the Xcode pin moved in #1300.

Verification

That release-candidate build, with notarization skipped, now signs, deploys to /Applications, and passes verify-installed-app.sh with Kanata registered, running, and TCP-ready.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[claude]

Reviewed this diff. No actionable correctness/reliability/security/performance/test-coverage findings — the change removes -Xswiftc -no-whole-module-optimization and restores default WMO for release builds, and the added comment clearly documents why the old workaround was added and why it now conflicts with the newer default SwiftPM build system. This is a straightforward, well-justified revert with nothing else touched.

One thing worth keeping in mind (not blocking): restoring WMO for release builds can noticeably increase build time/peak memory during swift build --configuration release compared to per-file compilation — worth a quick sanity check on CI/build-machine build times after this merges, since that's the exact tradeoff the original August 2025 workaround was made to avoid (for a different reason, a hang, but the resource profile is similar).