feat: revalidate device permissions against OS state before use

[TarikGul]

Device permissions carry two gates, not one. The product decision is persisted once and never expires. The OS grant behind it belongs to the host application and moves on its own: the user can revoke it in system settings, device policy can suspend it, and the platform can reset it, as Android does for apps that go unused.

A device capability is usable only while both gates are open. That holds for a product calling request_device_permission and for a host settings screen reading through CoreAdmin, so the two cannot disagree. A screen reporting Authorized for something a request reports as granted: false sends the user after a product toggle that was never what blocked them.

The seam

PermissionStatusHost is an optional platform capability with one method, device_permission_status, which reports OS state and must not prompt. It stays separate from Permissions::device_permission because that call also puts the product's question to the user, so it cannot re-check a decision the user has already made.

It sits on OptionalPlatform, so codegen emits it as an optional group: permissionStatus? on the JS host callback surface. A host that omits it resolves device grants from stored state alone, which is what a host with no OS permission model does anyway.

The rule

Only an OS refusal overrides the stored decision.

• An OS refusal denies without prompting, since only system settings can reach it. The stored product decision stays in place for when the user restores the OS grant.
• An undetermined OS status changes nothing. The OS raises its own dialog when the capability is used, and the core cannot reach that dialog without re-asking a question RFC 0002 step 3 treats as settled.
• A failed status query falls back to the stored decision. A dropped IPC is transient, and reading it as a refusal would let a flaky channel revoke a working capability.

Remote, identity disclosure and account access decisions have no OS gate and are untouched. Every product scoped permission service is built through one helper on ProductRuntimeHost, so the request and read paths cannot drift apart.

Hosts

Native. HostCallbacks carries device_permission_status, and CallbackPlatform serves the capability. The adapter travels on ConnectionAdapters rather than the host runtime, because a native host builds one CallbackPlatform per product execution, and the object reporting OS state has to be the one presenting the prompt.

The Swift protocol extension and the Kotlin interface both default the new member, so an embedding app compiles unchanged and opts in by implementing one method. Answer it from AVCaptureDevice.authorizationStatus(for:), UNUserNotificationCenter.getNotificationSettings, or ContextCompat.checkSelfPermission.

The callback returns NativeDevicePermissionStatus, a same namespace mirror of DevicePermissionStatus with a total conversion. UniFFI lowers a cross namespace type in an async callback return into the wrong RustBuffer, and the generated Kotlin then fails to compile.

WASM. The adapter installs when the JS side supplies devicePermissionStatus, including through the Web Worker, whose init message reports the capability so the worker proxies the callback.

CLI. Reports NotApplicable for every capability, since a terminal has no OS permission gate.

Known limitation

granted: false covers both a product refusal and an OS refusal, so neither a product nor a settings screen can tell "you declined this" from "the OS revoked this, open system settings". The remedies differ. Separating them needs a richer device permission response than the current boolean, so it waits for a breaking change window.

Android auto reset surfaces as an undetermined status, and re-requesting is the host's call, because a permission protected Android call throws rather than prompting.

Verification

Eighteen tests. Fourteen cover the decision matrix in host_logic::permissions. Three drive a real permissions_request_device_permission frame and a CoreAdmin status read through the generated dispatcher. One drives the native chain end to end: foreign callback, platform adapter, connection adapters, permission service.

Every test was confirmed to fail under a deliberate mutation, including dropping the OS refusal override, re-prompting on an undetermined status, mapping a query failure to a refusal, clearing the stored grant on refusal, dropping the read path gate, an installer that stores nothing, and an execution that stops passing its adapter. The integration and native tests are the only cover for the wiring, since the unit tests construct the service directly and survive every plumbing mutation.

Clean under RUSTFLAGS="-D warnings": cargo build --workspace --all-targets --all-features, cargo check --target wasm32-unknown-unknown -p truapi-server, cargo +nightly fmt --check, cargo +nightly clippy --workspace --all-targets --all-features -- -D warnings, and cargo test --workspace --all-features. sync-bindings.sh --check and make provider-swift-check both report the committed bindings current against a freshly generated tree.

Both native gates were compiled rather than reviewed: xcodebuild build-for-testing -scheme TrUAPIHost against the simulator, which is what compiles the hand written conformers, and make android-check.

make android-check also needed NativeCustomRendererObserver.onError implemented in the Kotlin conformer. That is unrelated to permissions and carried in its own commit. No CI job covers Android, so the gate had drifted.

Part of #334.

[Imod7]

In js/packages/truapi-host/src/web/create-worker-host-runtime.ts, line 833:

          capabilities: { chat: host.chat !== undefined },

This never reports permissionStatus, so the worker does not proxy devicePermissionStatus and no revalidation happens in the browser. I tested it: the init message carries {"chat":false} even when the host serves the capability. Please add permissionStatus: host.permissionStatus !== undefined. The two toEqual assertions on capabilities in worker-provider.test.ts then need the new key, and makeHostCallbacks in test-support.ts needs a permissionStatus branch like the chat one.

[pgherveou]

approving to unblock, will give a more torough review later this evening

[pgherveou]

my review here https://gist.github.com/pgherveou/cac4ac5c929118f5c99d4b8a58e11f90