arcane-os 0.56.0 → 0.58.0

package/docs/reference/core-client.md

@@ -124,6 +124,86 @@ developer diagnostics, rather than ordinary
 product status surfaces. The optional `onError(error)` callback observes
 transport/event-owner failures outside individual request promises.
 
+## Optional WebKit document lifetime
+
+`webKitDocumentLifecycle:true` on `createCoreClient`, `installCoreClient` or
+`createCoreClassicSource` selects document lifetime handling for the native
+WebKit `arcane` handler with replies. It defaults to `false`; existing WebKit
+plain-JSON and alternate acknowledgement transports, WebView2, Android,
+development HTTP and supplied transports keep their existing behavior. The
+selected host must implement this contract and the existing `runtime.replay`
+control. Install the classic source at document start in the page's world.
+
+The client owns a fresh activation for the current JavaScript realm and each
+restoration from the browser's page cache. WithReply receives these transport
+records; the Core JSON string remains unchanged in its separate `json` field:
+
+| Record | Meaning |
+| --- | --- |
+| `{type:'activate', activation}` | Attach this activation before sending its Core frames. |
+| `{type:'frame', activation, json}` | Send the complete serialized Core request or control. |
+| `{type:'retire', activation, json}` | Retire this activation; `json` is the existing `requests.cancelAll` control. |
+
+Reply with `{accepted:true}` or `{accepted:false,error}` on the initiating
+WithReply promise. Frame and retirement acceptance follows the actual complete
+process write. Queue admission alone is insufficient. Activation acceptance
+follows the host's current-realm probe and any required prior-owner cancellation.
+Only this activation's outgoing frames wait for attachment; page rendering,
+facade installation and independent Core startup remain concurrent.
+An aborted, timed-out or otherwise cancelled request awaiting attachment is
+never submitted afterward; its existing cancellation control remains observable.
+
+The host calls `__arcaneWebKitDocumentCurrent(activation)` in the current main
+document's page world to probe a candidate. A token or native frame descriptor
+alone does not identify the active document. Serialize candidate probes and
+Core ingress ownership changes: finish each candidate's probe before processing
+the next announcement, and leave the current owner unchanged when a probe is
+false. Announcement arrival order cannot establish document order. A true
+probe establishes the realm at that execution instant; every later delivery
+still checks its target at execution time.
+
+Before accepting a replacement activation, write the existing
+`requests.cancelAll` control for the prior ingress owner. Do not wait for a
+retirement announcement that a destroyed document may never send. Write a
+retirement record's JSON only while that activation still owns ingress;
+reject a late retirement without cancelling the replacement's requests.
+Record request-ID-to-origin-activation correlation before submitting each
+request to Core. Responses retain that origin. Existing generic service events
+remain broadcasts to the current activation; no request association is added.
+Complete native diagnostics retain frames received while no document is active;
+restoration uses current-state replay rather than historical event delivery.
+
+Deliver through `__arcaneReceive(json, activation)` and
+`__arcaneTransportFailed(error, activation)`, passing payloads as native
+JavaScript call arguments. Both return `false` for a retired or different
+activation. Receive also returns `false` for an unrecognized frame or a
+response with no pending request; `true` means the client accepted delivery,
+which may still await its shared event owner. Failure returns `true` when it
+ends that active installation. Preserve actual evaluation failures through the
+native diagnostic owner; a `false` result is not a JavaScript exception.
+`client.acceptsNativeDelivery(activation)` exposes the same synchronous lifetime
+predicate. It accepts any activation while a client using an ordinary transport
+is live. Direct owner calls to `client.failTransport(error)` retain their
+existing terminal-failure semantics.
+
+Page hide synchronously retires the activation even with no pending requests.
+It clears completed ready state and rejects every pending renderer promise with
+the existing `ARCANE_REQUEST_ABORTED`/`AbortError`. This ends the page's wait;
+the runtime's cancellation skips service-lifetime work, so an accepted save
+continues and participates in graceful drain. Its eventual response stays with
+the retired activation and cannot settle a restored page's request. The client
+does not claim that cancellation rolled back persistence.
+
+Persisted page restoration creates a fresh activation and sends exactly one
+`runtime.replay` after native attachment. Initial attachment sends that replay
+only when `replayRuntimeState:true`. Application subscriptions survive page
+hide and restoration, including registrations awaiting the shared event owner
+and ready listeners awaiting their replay microtask. Queued deliveries from a
+retired activation are no longer applicable to those subscriptions. Replay
+supplies current Core/service state, not prior responses or request promises.
+Closing the client retires once, removes lifecycle listeners and restores its
+owned callbacks. It does not close the process or control application shutdown.
+
 ## Classic native-host injection
 
 ```js

package/docs/reference/core-native-packaging.md

@@ -1,22 +1,32 @@
 # Portable Core packaging
 
 `arcane-os/native/portable-provider` owns the portable native payload in the SDK
-package. It does not load Arcane OS source, choose models, download a runtime,
-or compile an executable. Windows, Linux and macOS hosts may compose this
+package. It does not load Arcane OS source, choose models or compile an
+executable. An application's explicit `native.localAI` selection can include
+its selected upstream runtimes through the SDK local-AI installer. Without that
+selection, assembly does no local-AI runtime preparation. Windows, Linux and macOS hosts may compose this
 Node-based payload; Android needs its separate native host adaptation. The
-current CLI's portable platform selections remain Windows and Linux. A portable
+current CLI's portable platform selections include Windows, Linux and macOS. A portable
 artifact is not a Windows executable, Linux package or Android application.
 
 `loadArcaneNativeProvider({target:'portable'})` selects the installed SDK provider
 without an `arcaneRoot`. Supplying an explicit `arcaneRoot` retains the existing
-checkout-provider route. Other native targets remain with their actual platform
+checkout-provider route. The SDK also owns the `windows-x64` executable provider
+described below. Other native targets remain with their actual platform
 providers; the loader does not substitute this payload for an unavailable host.
 
 ## Provider and selected input
 
 The default export and `arcaneNativeBuilderProvider` are the same provider.
-`createPortableNativeProvider({services:[]})` creates one with application-owned
-service configuration. All implement `arcane-native-builder/1`:
+`createPortableNativeProvider({services,packagedWeb=false,webKitDocumentLifecycle=false})` creates one with application-owned
+service configuration. Without that override, the provider uses the selected
+app descriptor's `native.services`, or an empty selection when omitted. An
+explicit `services:[]` overrides the descriptor with no app services.
+The Mac provider selects `packagedWeb:true` to compose the SDK's packaged-web
+Core service and `webKitDocumentLifecycle:true` for the canonical classic-client
+activation/replay contract. Both default to false, preserving ordinary portable
+and Windows composition.
+All implement `arcane-native-builder/1`:
 
 - `describe()` identifies the portable target and `executable:false`.
 - `doctor({targetRequest, signal, onEvent})` reports missing SDK Core source files.
@@ -42,6 +52,45 @@ receipts, hashes, content limits or security policy. The package-relative source
 root comes from the provider module's own location, not `toolchainRoot` or an
 Arcane OS machine bundle.
 
+## Native-only application resources
+
+Select application service modules and their complete local source closure in
+the authored schema-2 descriptor's `package.nativeResources`, separately from
+its browser `include`/`exclude` selection:
+
+```json
+{
+  "package": {
+    "nativeResources": {
+      "include": ["native", "src", "package.json"],
+      "exclude": ["native/drafts"]
+    }
+  }
+}
+```
+
+This is a descriptor excerpt for the app-owned service example below. The
+projected schema-1 field is top-level `nativeResources`. Paths are literal and
+app-relative; directories include descendants. Omission or an empty include
+keeps previous selection and output behavior. The app supplies every required
+source file explicitly; packaging does not discover or execute services.
+
+Paired `buildApplication()` passes the actual native target to the selected app
+and every explicitly bundled app. With a nonempty native include list, their
+input releases use `dist/.native/<target>/<app-id>` instead of the saved browser
+output, preserving existing browser/PWA artifacts. Each app's own selection is
+applied; complete releases and actual roots are forwarded to the provider.
+The provider then copies them unchanged into its artifact layout described below.
+
+At the low-level `packageApp()` boundary, `target` defaults to `'browser'` and
+is independent of `moduleFormat`. Nonbrowser selection disables generated PWA
+content. Native-only files bypass browser document/module/asset transformations;
+a file also in the ordinary browser selection retains that existing processing.
+An explicit low-level `outputDirectory` still wins. Inspect the emitted input
+with `verifyApp({workspaceRoot,appId,outputDirectory:release.output})`; neither
+that inventory verification nor packaging launches the service or platform host.
+See [the complete selection contract](protocols.md#native-only-application-resources).
+
 ## Output and host contract
 
 Each build creates a fresh `arcane-portable-*` directory beneath `outputRoot`.
@@ -85,7 +134,9 @@ host must:
 1. Mount `app/` at the root of its local application URL origin, preserving the
    selected start path and all navigable documents.
 2. Inject `runtime/arcane-api.js` at document creation. It is produced by the
-   canonical `createCoreClassicSource()` generator, not a copied OS client.
+   canonical `createCoreClassicSource()` generator with `replayRuntimeState:true`.
+   Once its transport listener is attached, each document requests the current
+   Core and service state without starting services again.
 3. Start `runtime/arcane-core.mjs` with the host's supported Node runtime and
    connect the existing framed stdin/stdout transport.
 4. Close input and await Core's drain before terminating the child process.
@@ -100,7 +151,21 @@ is not the native serving contract. No host is launched during packaging.
 
 ## Explicit application services
 
-Pass native service modules already included in the selected app release:
+For the ordinary SDK build command, select native service modules in the
+application's authored descriptor. Include their source closure through
+`package.nativeResources` as described above:
+
+```json
+{
+  "native": {
+    "services": [
+      {"module":"native/moon-ledger.mjs", "options":{"ledgerName":"Cheese debts"}}
+    ]
+  }
+}
+```
+
+Direct SDK compositions can instead pass that selection to the provider:
 
 ```js
 import {createPortableNativeProvider} from 'arcane-os/native/portable-provider';
@@ -111,7 +176,8 @@ const nativeBuilder = createPortableNativeProvider({
 ```
 
 Each module default-exports a synchronous factory returning the existing Core
-service definition. Its options must be JSON-serializable data. Module imports
+service definition. Its first argument is the complete authored options record;
+its second is the shared launch context described below. Options must be JSON-serializable data. Module imports
 and factories run only when the generated Core entry is launched, never during
 packaging. Put asynchronous initialization in `start()`, not a top-level await
 or asynchronous factory, so unrelated services and dispatcher readiness remain
@@ -142,8 +208,234 @@ observable through `onError` and `closed`; no process is killed or forcibly exit
 See [the Core runtime contract](core-runtime.md) for request and service lifetime
 details and [the client contract](core-client.md) for native bridge integration.
 
-This source increment supplies portable assembly and service composition.
-Desktop WebView executables, platform child-process ownership, Android dispatch
-and executable build toolchains require their own completed adapters. Published
+## Launch-time locations
+
+The generated Core entry accepts `--arcane-launch-config <path>`. The public
+`readCoreLaunchContext({argv=process.argv.slice(2)}={})` function in
+`arcane-os/core/host` reads that explicitly selected JSON object. Without the
+flag it returns `{}`. Missing files, missing flag values and malformed JSON
+report their actual errors; the reader does not search for configuration,
+rewrite it or change the process environment.
+
+The generated entry supplies an artifact-derived `appRoot` and then applies the
+complete explicit launch context. Every service factory receives that same
+object as its second argument, preserving its authored first argument. A
+launcher can supply the user's selected `workspaceRoot` and writable
+`stateRoot` at launch instead of embedding this machine's paths in an app
+package. The host owns those selections; the SDK does not choose a product's
+workspace, namespace, saved preferences or models. JSON values and additional
+application-owned fields remain unchanged.
+
+## Selected local-AI runtimes
+
+When `appDescriptor.native.localAI` is present, portable assembly calls the
+SDK's `bundleLocalAIRuntimes()` owner with its `runtimes` selection and the
+requested target platform/architecture. Its reusable installation directory is
+`<outputRoot>/local-ai-runtimes`; each new payload receives the complete selected
+runtime trees beneath `runtime/local-ai/`. Runtime preparation and app copying
+proceed independently and both settle before assembly can clean up an incomplete
+output. No application service or model executes during packaging.
+
+`manifest.core.localAIRuntimes` records the bundled runtime locations relative
+to the artifact root. Only the explicitly configured entry imports
+`createLocalAIService` from `arcane-os/core/local-ai`. It resolves those bundled
+locations against the installed artifact and supplies them in the launch
+context's `runtimes` array, alongside `appRoot`, before applying explicit launch
+configuration. It passes the complete authored `native.localAI` record to the
+factory. Applications without that selection have no generated local-AI import
+or service. Availability of a particular engine belongs to the selected
+local-AI installer and service; a generic ONNX runtime is not a speech model.
+
+Selected `onnx` bundles its complete managed `onnxruntime-node` dependency tree.
+Its `modulePath` resolves against the artifact root just as a server runtime's
+`executable` does. Library/module records need no executable. The generated Core
+service exposes retained worker sessions through `onnx.load/run/unload/status`;
+model files remain caller-selected application resources. See
+[native ONNX sessions](local-ai.md#native-onnx-sessions).
+
+## Windows executable
+
+The ordinary application command is:
+
+```sh
+npm exec -- arcane build --target windows-x64
+```
+
+`loadArcaneNativeProvider({target:'windows-x64'})` selects the SDK's own
+`arcane-os/native/windows-provider` without an OS checkout or `arcaneRoot`.
+Its default export and `arcaneNativeBuilderProvider` are the same provider;
+`createWindowsNativeProvider({services,hostDirectory})` permits explicit
+same-project composition. Service selection follows the portable provider's
+descriptor/override contract above.
+
+The provider assembles the selected app with the precompiled host asset
+`arcane-native-windows-x64.tar.gz` from the numeric GitHub release matching the
+builder's installed SDK version. The asset contains the launcher, WebView2
+support libraries, Node SEA Core executable and required license files. It does
+not select the newest host independently of that package. Downloads occur only
+during `build()`, use the caller's output directory, and are reused from
+`<outputRoot>/.arcane-native-hosts/<sdk-version>/windows-x64`. The build machine
+needs the standard `tar` command for extraction; application builds do not need
+a C# compiler, system Node installation for the generated executable, or host
+source scripts. The SDK build command itself still runs through the application's
+normal Node/npm toolchain.
+
+An explicit `hostDirectory` selects an already-built complete host tree instead
+of downloading one. This is useful for SDK collaborators verifying the next
+host output; downstream applications use the published package and matching
+release asset. `doctor()` reports the selected prerequisites and missing files;
+it does not download the host or probe the installed WebView runtime.
+
+The assembled directory contains `Arcane.exe`, the unchanged `app/` payload,
+Core runtime and semantic `arcane-native.json`. Launch `Arcane.exe` on Windows
+x64 with the Microsoft Edge WebView2 Runtime installed. It opens the selected
+app in WebView2 and owns its framed connection to the bundled Core process.
+`verify()` observes the assembled files and manifest; it does not execute the
+window or prove application behavior. `run()` launches the executable and
+observes complete diagnostics and exit. Cancelling that operation closes its
+input, allowing the window and accepted Core service work to drain without a
+forced process termination.
+
+For explicit user-selected workspace/state locations, launch:
+
+```sh
+Arcane.exe --arcane-launch-config path/to/launch.json
+```
+
+The complete JSON object reaches the service factories as their second
+argument. A supplied `stateRoot` also owns the WebView2 profile and diagnostic
+directory. Otherwise the launcher uses the current user's local application
+data under `Arcane/<app-id>`. The launcher does not invent an application
+workspace. Relative launch-file paths resolve from the invocation's working
+directory. `--close-on-stdin-eof` is an explicit process-owner option used by the
+SDK runner; an ordinary double-clicked window closes through its own UI.
+
+## Windows host source and selected output
+
+The SDK's `src/core/hosts/windows/ArcaneCoreProcess.cs` owns an explicitly
+selected executable, argument string and working directory. It reads complete
+framed Core messages and diagnostics, acknowledges ordered asynchronous writes,
+and closes stdin before awaiting accepted Core work, final output and process
+exit. It does not kill the child on an ordinary close.
+
+`ArcaneHost.cs` composes that process with a WebView2 window through
+`ArcaneHost.Run(options,onDiagnostic,onError)` or `ArcaneHostForm`. Options
+select the app root/start path, stable virtual HTTPS origin, profile directory,
+title, canonical classic-client source and Core process inputs. The form exposes
+`Ready`, `Completion` and `CloseAsync()`. Page navigation, transport connection,
+Core readiness and service readiness are separate states. Accepted work drains
+before the window closes; complete engineering errors go to the supplied
+diagnostic/error callbacks. Callbacks must not synchronously wait for the
+window's lifetime promises.
+
+`ArcaneLauncher.cs` supplies the executable entry point for that composition.
+`tools/build-core-windows-host.mjs` builds the selected SDK host output from the
+approved WebView2 package, existing .NET Framework compiler and selected Node
+SEA output. It retains complete compiler diagnostics and produces a fresh
+directory rather than overwriting an earlier artifact. The host requires
+.NET Framework 4.6.2 or later. This is SDK release tooling, not an application
+build requirement. Source compilation, selected host execution and real
+application behavior are separate evidence boundaries; an assembled app is not
+an installer or proof of its domain behavior.
+
+Linux, macOS, Android dispatch and each platform's output verification retain
+their separate delivery boundaries. Published
 consumers must adopt the numeric package that includes this increment; a source
 checkout or a successful source push is not that public package authority.
+
+## macOS process source
+
+`src/core/hosts/macos/ArcaneCoreProcess.h` and `.m` provide a Foundation-only
+adapter for macOS 11 or later, compiled with Objective-C ARC and blocks. A
+composing host explicitly supplies the executable URL, arguments, working
+directory and delegate; startup is asynchronous. Delegate callbacks deliver
+every raw stdout/stderr chunk and complete opaque framed JSON bodies, plus
+launch, error, exit and final completion observations. Each stream and accepted
+write retains its own order; UI dispatch belongs to the host. Callbacks must
+return normally and must not wait for another callback or completion.
+
+`sendJSONData:completion:error:` accepts an ordered write or reports a
+synchronous rejection. Write completion means the frame reached stdin, not that
+the RPC succeeded. `closeInput` rejects new sends, finishes accepted writes and
+closes stdin, then keeps observing output and child exit without a forced
+termination deadline. The delegate is retained through final completion.
+The AppKit `ArcaneHost` and launcher compose that source as described below.
+Compilation and execution on macOS remain separate evidence from the selected
+Windows output.
+
+## macOS application composition
+
+`arcane-os/native/macos-provider` exports
+`createMacOSNativeProvider({services,hostDirectory}={})`, its named
+`arcaneNativeBuilderProvider`, and the same provider as default. The six-method
+contract accepts `macos-arm64` or `macos-x64`, `platform:'macos'`, `format:'app'`
+and the existing unsigned local development selection. Ordinary CLI routing
+uses the SDK package, not an Arcane OS checkout:
+
+```sh
+npm exec -- arcane build --target macos-arm64
+npm exec -- arcane run --target macos-arm64
+```
+
+Select `macos-x64` for Intel. The descriptor must declare the selected target.
+Source implementation does not establish that an architecture's host artifact
+has been built, executed or published. Consumer assembly needs the exact numeric
+SDK release asset `arcane-native-macos-<architecture>.tar.gz`; unavailable assets
+produce their actual download error. SDK collaborators may select an existing
+`hostDirectory` explicitly. There is no fallback to source checkout, another
+version, another architecture or a browser-only artifact.
+
+The complete unchanged portable payload lives at
+`<app-id>.app/Contents/Resources/`. That directory remains `target.rootDir` and
+contains `arcane-native.json`, `app/`, dependency releases, installed SDK files,
+Core entry/client and `runtime/node`. The additive `bundleRoot` identifies the
+`.app` directory. `Contents/MacOS/Arcane` and `Contents/Info.plist` belong to the
+bundle rather than the web root; the Mac owner checks these separately from the
+Resources file inventory. Application identity supplies the stable bundle ID
+`org.arcane.<app-id>`. Executable permissions are preserved for the launcher and
+selected Node runtime.
+
+The launcher opens its window immediately and starts one Core child. The
+generated Core entry starts the `packaged-web` service alongside application
+services, without waiting for models. Only `core.web.ready`, emitted after the
+actual listener is ready and the initial port is saved, supplies the application
+URL to WebKit. It serves the complete `manifest.webRoot` at `/` and resolves the
+complete `manifest.start`, including query and fragment, against that origin.
+The classic client selects current-document activation and sticky state replay;
+navigation does not restart the Core service or replay retired requests.
+The host's main-thread readonly `isClosing` accessor exposes its existing close
+intent; an unsolicited Core exit is therefore reported separately from an
+ordinary user-requested drain, even when the process exits successfully.
+
+`createPackagedWebService({artifactRoot}, context={})` is available from
+`arcane-os/core/packaged-web`. It uses the existing
+`startDevServer({mode:'packaged',http:true,host:'127.0.0.1',port,releaseRoot})`
+owner and published `node-http-server`, not a second HTTP implementation.
+`context.stateRoot` takes precedence over the launcher's separate
+`--arcane-host-state-root` argument. The launcher defaults to
+`~/Library/Application Support/Arcane/<app-id>`; an explicitly supplied launch
+file remains unchanged and is forwarded to Core. The first successful listener
+stores its selected port in `packaged-web-origin.json`. Later launches reuse it;
+a port conflict or unreadable saved record is reported without changing origins
+or discarding stored state.
+
+The app's persistent default `WKWebsiteDataStore` uses its bundle identity.
+`stateRoot` selects Core state and diagnostics, not a custom WebKit profile
+directory. Browser API availability, OPFS and secure-context behavior remain
+WebKit-owned and require actual Mac verification; the SDK bypasses no browser
+policy. Startup failures use `core.service.state` for `name:'packaged-web'`;
+unexpected listener closure or failure uses `core.web.failed` with the complete
+serialized error. Native alerts show a concise outcome, with full diagnostics
+outside the conversation. Core drains accepted work and the listener before
+the native close completes. The optional runner stdin-EOF signal uses that same
+path; ordinary double-click startup does not wait on stdin.
+
+`tools/build-core-macos-host.mjs` is SDK host-release tooling, not an application
+compiler requirement. It accepts an explicit Darwin Node executable and its
+license, compiler path, `arm64` or `x64`, and output directory. It uses Objective-C
+ARC/blocks and Apple's Foundation, AppKit and WebKit frameworks. The host source
+targets macOS 11; the selected Node runtime may require a newer macOS version.
+Its actual runtime/platform/architecture and the SDK Node engine requirement
+must agree. Compiler/runtime execution and redistribution belong to the
+separately authorized selected host output. This source increment runs none of
+them and claims no Mac build or execution result.

package/docs/reference/core-preferences.md

@@ -0,0 +1,49 @@
+# Core preferences service
+
+`createPreferencesService({file})` from `arcane-os/core/preferences` supplies the
+existing `Arcane.preferences` RPC methods to a native Core host. The default
+export is the same factory. Construction performs no filesystem work. The
+application selects its writable file and owns preference names, defaults and
+schemas; this service does not invent them or alter operating-system settings.
+
+```js
+import path from 'node:path';
+import {createPreferencesService} from 'arcane-os/core/preferences';
+
+export default function createMoonPreferences(options, context) {
+    return createPreferencesService({
+        file: path.join(context.stateRoot, 'moon-preferences.json')
+    });
+}
+```
+
+Select this application-owned factory through `native.services`, and include it
+in `package.nativeResources`. Supply the application's selected `stateRoot`
+through the explicit launch configuration. See [native packaging](core-native-packaging.md#launch-time-locations).
+
+| Method | Input | Result |
+| --- | --- | --- |
+| `preferences.list` | `{}` | `{keys}` in sorted order |
+| `preferences.get` | `{key}` | `{key,found,value}`; missing value is `null` |
+| `preferences.set` | `{key,value}` | `{key,value}` after file replacement |
+| `preferences.setMany` | `{entries}` | `{keys,count}` after file replacement |
+| `preferences.delete` | `{key}` | `{key,deleted}` |
+
+Storage remains `{schemaVersion:1,entries}`. Exact keys, complete JSON values and
+additional existing document metadata are retained. A missing file starts with
+empty entries; reading it does not create a file. Unreadable or malformed files
+report their real errors and are not replaced with an empty record. Values that
+JSON cannot represent completely fail before replacement. There is no migration,
+truncation, namespace rewrite, default injection or frozen result.
+
+Operations selecting the same resolved filename share one ordered queue within
+the Core process. This is not a cross-process file lock. Writes flush their new
+content and replace the selected file before acknowledgment. Filesystem failures
+remain observable, including cleanup errors; this is not a claim of survival
+across every hardware or operating-system failure.
+
+`set`, `setMany` and `delete` use `lifetime:'service'`: renderer cancellation does
+not discard accepted writes. `drain()` and `dispose()` stop acceptance and wait
+for accepted operations; later calls reject with `CORE_CLOSING`. Read operations
+observe their request cancellation. Use the existing Core host shutdown owner
+so saved preferences finish before the native process exits.