fix(ios): strip the provider xcframework modulemaps

[Imod7]

Related to #442

Description

The published @parity/ios-provider xcframework ships a module.modulemap in each slice. Xcode flattens every slice's Headers into one include directory, so it collides with any other UniFFI xcframework in the same app and the release asset cannot be used. Staging now strips them, the way the host package already does, and both publish.sh scripts refuse a framework that still carries one.

New ios/truapi-provider/scripts/stage-xcframework.sh, called by rebuild.sh, covered by scripts/lib/xcframework-staging.test.mjs. The module keeps resolving through the committed Sources/truapi_providerFFI/include/module.modulemap, which is untouched. Docs only: Package.swift and the README no longer say no release exists, and rebuild.sh prints TRUAPI_PROVIDER_USE_LOCAL_BINARY=1, the variable the binary target reads.

Testing

The published asset is the defect, so the check stages it with the new script.

tree	modulemaps	headers	libraries	Info.plist
published 0.7.0	2	2	2	yes
same tree, staged	0	2	2	yes

diff -r between the two reports the two modulemaps and nothing else. The publish guard, run in isolation, exits 66 on the published tree and 0 on the staged one. npm run test:scripts passes 39, four of them new. swift package dump-package parses.

Not run locally: building the framework from source needs Xcode, and publish.sh creates a GitHub release. CI's ios-swift job runs rebuild.sh --sim-only, which now calls staging.

The published 0.7.0 asset stays unstripped. This fixes the next publish, not the last one.