chore: Publish v0.11.0 and repair Windows backend runtime

[huacnlee]

Publish Omamail v0.11.0 from current main, including the merged subject-copying and release-validation repairs. This release advances the published backend to API 7, enabling sender names for IMAP and Outlook accounts while retaining the fixed API gates in QML.

Stop the Windows persistent backend promptly when its response pipe closes, including while stdin remains open. Give the Windows backend entry thread an 8 MiB stack to avoid command and persistent-dispatch stack overflows. Restore Windows OAuth admission and default MIME boundary generation by using the same operating-system cryptographic random provider already used by IMAP cursors. Correct the native test fixtures for Windows filenames, absolute paths, UTF-8 Python transport, and connection-refusal latency. Isolate Windows CLI integration children from native user directories with a debug-only test feature; production builds ignore that hint. Give synthetic storage its required owner-only protected ACL and compare owner/DACL and timestamps in no-write assertions. Hostile attachment display names and the assertions against unwanted writes, sends, and credential-bearing requests remain covered.

Release CI builds the two static Linux backends and all three standalone desktop packages from one source commit. It verifies native security contracts, backend APIs, package installation and rollback, and smoke tests before publishing the complete immutable asset set. It downloads and verifies the public assets before committing backend-version and the folded API metadata on this branch. Merge only after that pin commit and the checks for its exact revision pass.

Validation

Release source 70c295b passed both static Linux backend jobs and the complete macOS, Linux and Windows standalone jobs in https://github.com/huacnlee/omamail/actions/runs/38136130747 (attempt 2). Native credential, private-file/IPC, process, network, QML, API, installation/rollback and smoke checks completed before publication. Windows passed 497 library tests, all 33 CLI tests and all three stdio regressions.

The authoritative workflow published all ten immutable assets, verified their public downloads, then committed only backend-version and the folded API metadata as 88bdf6a. The pin is now 0.11.0 and released API 7, with no unreleased API entries. Every exact-pin PR check passed before merging as 5db1774. All public assets were downloaded locally and passed checksum/layout verification; their source fingerprint matches the immutable v0.11.0 tag. Local Linux CLI integration tests (33) and MIME parity tests (9) passed; full local make validate was started with an isolated temporary directory but interrupted during compilation because of sustained machine load; authoritative native CI completed successfully.

Security: PASS for the affected release boundaries on all three native platform runners. Standalone archives retain the documented unsigned/unnotarized distribution limitations.

Release Notes

• Add a sender name for IMAP and Outlook mailboxes and support selections across accounts in the unified view.
• Right-click a message's subject to copy it in full, including text beginning with a dash.
• Fix Windows backend stack overflows, OAuth sign-in, and outgoing MIME generation.
• Update the Omarchy backend and standalone desktop applications to v0.11.0.

[github-actions]

CI failed at 70c295b (run). What each failed gate needs:

Released backend gate failed

The backend the plugin pins (backend-version) does not speak what backend-api.json calls its released API, or the released fixtures do not pass against it. Backends ship in batches, so an API change does not wait for a release — it is declared as the one unreleased step:

• raise apiVersion to exactly releasedApiVersion + 1;
• list every new method under unreleased.methods and every new or changed contract case under unreleased.cases;
• leave the released cases as they are — the pinned binary has to keep passing them;
• a feature that needs the step checks the connected backend against its fixed minimum API revision and waits until that requirement is met.
  If apiVersion is already a step ahead, the released view still changed: compare backend-api.json with the pinned release's copy (gh release download v$(cat backend-version) --pattern backend-api.json). See "Released and unreleased" in docs/BACKEND-RUNTIME.md.

Released backend gate failed

The backend the plugin pins (backend-version) does not speak what backend-api.json calls its released API, or the released fixtures do not pass against it. Backends ship in batches, so an API change does not wait for a release — it is declared as the one unreleased step:

• raise apiVersion to exactly releasedApiVersion + 1;
• list every new method under unreleased.methods and every new or changed contract case under unreleased.cases;
• leave the released cases as they are — the pinned binary has to keep passing them;
• a feature that needs the step checks the connected backend against its fixed minimum API revision and waits until that requirement is met.
  If apiVersion is already a step ahead, the released view still changed: compare backend-api.json with the pinned release's copy (gh release download v$(cat backend-version) --pattern backend-api.json). See "Released and unreleased" in docs/BACKEND-RUNTIME.md.

Fix, push, and the gates run again; this comment updates itself.