Story: Hotfix: Apple's libc++ has no C++20 stop machinery at all

The macOS legs are red again, one hour after the portable thread was added:

stoppable_thread.hpp:99:24: error: no type named 'stop_token' in namespace 'std'
stoppable_thread.hpp:113:10: error: no type named 'stop_source' in namespace 'std'

The earlier story assumed the gap was std::jthread alone, because the error named only that type and the engine's lambda took a std::stop_token without the compiler complaining. It did not complain because the declaration holding the lambda had already failed. With that fixed, the next error is the token: Xcode 16.2's libc++ implements neither std::stop_token nor std::stop_source.

The lesson is the one the estate already applies elsewhere: when a platform gap is found, do not assume its boundary from one diagnostic. The shim now depends on nothing a supported library can be missing.

• stoppable_thread carries its own stop_source: a shared atomic flag with request_stop() and stop_requested().
• No source in the estate names std::jthread, std::stop_token or std::stop_source.
• The tree builds, the workflow and platform suites pass, and the macOS legs build and test.

• The stop machinery is implemented in the shim rather than the standard types kept behind a preprocessor branch. A branch per platform would put the portability decision in the caller, which is what the concurrency header exists to prevent.
• The callable takes the shim's stop_source by value. Copies share the one atomic flag, so the callable can hold it without depending on the thread object's lifetime.
• The earlier story is corrected in place rather than left standing: it states that Apple implements the stop token and the stop source, which the second build disproved.

• The other macOS failures, if any, on a main that has moved since.