fix(macos): detect the App Sandbox; the updater refuses, MCP and extensions say why (#1593)

[ZhuchkaTriplesix]

Closes #1593.

The release builds are not sandboxed (#1592), but a debug build (DebugProfile.entitlements) and any store-style build are. In the sandbox the in-place update, extensions and MCP fail without a word.

• MacOsSandbox (lib/core/platform/macos_sandbox.dart): detect(environment) is true when APP_SANDBOX_CONTAINER_ID is set or HOME is inside ~/Library/Containers/; isActive is that on macOS, false elsewhere, with a debugOverride for tests; unavailable(feature) is the one message.
• Updater: UpdateInstallContext.macAppBundleReplaceProblemFor reports the sandbox before the translocation and writable checks from fix(updater): macOS in-place update can quit the app and leave a broken bundle #1587, so the update is refused with "download the new version from the release page" instead of the replace script quitting the app. This is the same pre-flight fix(updater): macOS in-place update can quit the app and leave a broken bundle #1587 added, so it runs both before the download and right before the replace.
• Preferences: the MCP and Extensions sections show the message under their description when sandboxed.

Verified on Linux only: the detection is pure and covered by tests, and the UI path runs through the override. I have no Mac to check that a debug run really sets these variables, but both are what the sandbox documents.

Tests: detection for the container id, a container HOME, an empty id and an ordinary environment; the override; the updater message for a sandboxed context; the Extensions notice with and without the sandbox.