build(desktop): pass macOS deployment target to Wails

[complyue]

Background

On macOS Monterey 12.7.6, the system WKWebView/JavaScriptCore is older than the WebKit version Safari has staged on the same installation. Reasonix's modern frontend bundle can therefore fail during JavaScript parsing before React mounts. The current failure reported in issue #7624 is:

Invalid regular expression: invalid group specifier name

It points at markdownRemarkPlugins and is caused by an old Monterey WebKit rejecting modern RegExp syntax. The result is the familiar black/error window and a large amount of misleading downstream React noise. This is a native runtime-version skew, not a Reasonix feature bug.

Reasonix has accumulated several app-local workarounds for this class of problem:

• #1215 removed lookbehind from the bundle and added a narrowly-scoped build transform.
• #2886 pinned mdast-util-gfm-autolink-literal to an older Safari-compatible version.
• #2883 stripped crossorigin from assets served over the Wails custom scheme.
• #6678 installed an Object.hasOwn polyfill before React imports.
• #7615 carried another legacy-WebKit-compatible local-path matcher.

These fixes made individual releases work, but they leave the application responsible for tracking the capabilities of the native engine.

Change

Set the existing standard desktop build script's macOS deployment-target default to 12.3:

• Monterey targets use Safari's staged WebKit through the paired Wails build change.
• macOS 13 and newer continue using the normal system WebKit path.
• The deployment target remains overridable by the build environment.
• The existing release workflow already invokes this script, so CI receives the same policy without a second macOS-specific workflow or linker implementation.

For a direct/manual Wails invocation, the equivalent is:

MACOSX_DEPLOYMENT_TARGET=12.3 wails build -platform darwin/amd64

The 12.3 floor is deliberate: the Safari staged framework set validated on Monterey declares macOS 12.3 as its minimum. Targets 12.0–12.2 cannot safely link that framework set and retain Wails' normal system-WebKit behavior.

Why the implementation is in Wails

This consumer PR intentionally contains no Safari path discovery, framework validation, DYLD flags, CGO flags, or JavaScript engine patch. Wails owns the native WebKit selection and applies it consistently to any Wails v2 application. Reasonix only supplies its supported macOS build target.

That keeps the final Reasonix maintenance surface to one environment default and makes the manual build, the standard packaging script, and the release CI path use the same contract.

Maintenance reduction

After the paired Wails change is available in a released dependency, the old engine-specific frontend workarounds can be reviewed for removal in a follow-up:

• delete the Object.hasOwn shim and its startup contract test;
• remove the Safari-only mdast package pin;
• remove lookbehind-avoidance transforms and matchers whose only purpose is the system WebKit floor;
• keep the crossorigin workaround unless a separate custom-scheme/CORS fix proves it redundant, because that workaround is not a JavaScript-engine issue.

The cleanup is intentionally not mixed into this PR: removing those guards before the Wails build behavior is available would make older release paths less safe and would obscure the actual dependency boundary.

Validation

• The paired Wails build package tests pass.
• bash -n scripts/desktop-build.sh and git diff --check pass.
• On macOS 12.7.6 Intel, the standard Reasonix desktop build completed with the local Wails fork.
• The resulting application binary advertises a 12.3 minimum, loads WebKit, WebKitLegacy, JavaScriptCore, and WebCore from Safari's staged framework directory, and passes deep strict code-signature verification.

Documentation-impact: none - the existing desktop build documentation remains correct; the new target is applied by the existing standard packaging script and the direct/manual override is shown above.

Sister PR

Wails implementation: wailsapp/wails#5903

This PR should be reviewed together with that Wails PR. The local verification used a temporary Go workspace pointing github.com/wailsapp/wails/v2 at the corresponding local fork; no permanent application-specific Wails fork or replace directive is added here.