darwin: stop leaking the .pod symlink into the production .app

symlink_pod.sh creates a `.pod` symlink in $SERIOUS_PYTHON_SITE_PACKAGES
pointing at the plugin's source tree so package_command.dart can invoke
sync_site_packages.sh from a stable path. That symlink is fine for the
host build step but should NOT end up in the production app bundle.

sync_site_packages.sh's macOS path used `rsync -av` which copies symlinks
as symlinks. The .pod symlink then landed in dist_macos/site-packages/
and CocoaPods packaged it into python.bundle/Contents/Resources/
site-packages/.pod. Two cascading failures observed during `flet build`:

  1. The .pod symlink resolved into the plugin source tree, which
     contains dist_macos/xcframeworks/Python.xcframework/.../Python.app
     (a small launcher inside the framework). macOS LaunchServices
     scanned the .app, found the embedded Python.app, and tried to
     launch it — DYLD couldn't resolve the framework binary at
     `Python.framework/Versions/3.14/Python`, repeated crash report
     popups.

  2. flet-cli's copy_tree from the codesigned Release .app to the final
     build/macos/<app>.app followed the symlink into the source tree.
     The xcframework files inside were treated as code-signed bundle
     resources, every copy attempt failed with `[Errno 1] Operation not
     permitted`, flooding the build log.

Excluding `.pod` from the rsync stops the leak at source. The iOS path
already happens to skip it (`cp -R src/*` doesn't expand dotfiles).

After this lands, existing local broken state needs cleanup once:
  - rm -rf the broken .app in your project's build/macos/<app>.app
  - rm -rf src/serious_python_darwin/darwin/dist_macos
  - re-run `flet build`

Author: FeodorFitsner

src/serious_python_darwin/darwin/sync_site_packages.sh

@@ -43,7 +43,16 @@ if [[ -n "$SERIOUS_PYTHON_SITE_PACKAGES" && -d "$SERIOUS_PYTHON_SITE_PACKAGES" ]
         dist=$script_dir/dist_macos
 
         mkdir -p $dist/site-packages
-        rsync -av --delete "$SERIOUS_PYTHON_SITE_PACKAGES/" "$dist/site-packages/"
+        # Exclude the .pod symlink created by symlink_pod.sh — it points at
+        # this plugin's source tree. If it lands in dist_macos/site-packages,
+        # CocoaPods packages it into the production .app, where macOS
+        # LaunchServices finds the embedded Python.app inside the symlinked
+        # Python.xcframework and tries to launch it (DYLD failure, repeated
+        # crash report popups), and `flet build`'s copy_tree follows the
+        # symlink into a code-signed source tree and hits EPERM on every
+        # file. .pod is only needed by package_command.dart at packaging
+        # time to invoke this sync script; it does not belong in the bundle.
+        rsync -av --delete --exclude '.pod' "$SERIOUS_PYTHON_SITE_PACKAGES/" "$dist/site-packages/"
     fi
 else
     echo "SERIOUS_PYTHON_SITE_PACKAGES is not set."