[AeneasTews]

Problem and change

On macOS, serious_python_run() starts its asynchronous Python worker with default pthread attributes. The small secondary-thread stack has caused native scientific imports and NumPy work to fault, while synchronous execution on the main thread succeeds (see flet-dev/serious-python#85).

This patch requests at least 8 MiB for that worker using pthread attributes. It preserves any larger platform default, cleans up the attributes on every path, and reports a spawn failure if the stack cannot be configured. Other platforms and synchronous execution keep their current behavior. The public C config and Dart FFI layout do not change.

Validation

• Linux CMake release build passes with the unchanged POSIX path.
• git diff --check passes.
• On an Apple Silicon macOS 26.6.2 host, a fresh Flutter app using published
  serious_python 4.7.0 / Python 3.12 measured 536,576 bytes (524 KiB)
  inside the embedded worker before importing NumPy. Xcode successfully built
  the 156.4 MB release app, Flutter launched it, printed the stack measurement,
  and then reported Application finished. without a NumPy result. This
  reproduces a runtime termination in the probe after the stack measurement.
• Replacing only that temporary app's embedded dart_bridge binary with this
  PR's macOS build (09c2f57), then locally re-signing the app, measured
  8,400,896 bytes inside the worker and completed the same NumPy dot
  product with numpy=ok.
• The reproducible Mac probe
  contains both commands. The local binary is built for the host architecture
  and ad-hoc signed; the release pipeline must still build/sign the full Apple
  XCFramework. SciPy/h5py and Intel macOS remain untested here.

After this bridge is released, Serious Python can pin the new artifact through
its python-build manifest and generated version tables.

[CLAassistant]

All committers have signed the CLA.