Confine every native provider and stop handing it the device key #166

Part of #173 (isolation plan); related: #83, #84.

Native providers run as ordinary child processes of the Runtime: same OS user, inherited environment, no OS sandbox (elastos/crates/elastos-runtime/src/provider/bridge.rs:848-861). Only model-provider is confined (macOS seatbelt, bridge.rs:318; Linux seccomp with no Internet sockets and no_new_privs, provider/linux_model_seccomp.rs). The device key is handed to the did, localhost, object and wallet providers as encryption_key (elastos-server/src/server_infra.rs:749, 792, 892, 1305). A parser bug in a provider that handles untrusted input (object, media, ipfs, chain) therefore runs code with the full rights of the Runtime account and its keys. SECURITY.md:66 says "Capsules run sandboxed (WASM or microVM)", which does not describe providers.

Done means

• Every native provider except model-provider starts under a confinement profile. On Linux: no_new_privs, seccomp and Landlock, and no network namespace access unless declared. On macOS: a deny-default sandbox profile. Each provider gets only the files, sockets, network and child programs its manifest declares. A test proves a provider cannot open files or network destinations outside its profile.
• The model provider passes LA-05: Enforce Linux model process isolation #99's confinement tests.
• Key rule: the device key goes only to the did provider. Wallet keys go only to the wallet provider. The object and localhost providers get a per-provider storage key derived by the Runtime, never the device key (today they receive the device key, elastos/crates/elastos-server/src/server_infra.rs:792,892). Every other provider gets no key. Test: each provider's configuration and environment contain only the key it is listed for, and existing encrypted data is still readable after the change.
• A provider whose profile cannot be applied on the current platform does not start (fail closed). A proof exists on Linux x86-64, Jetson and macOS.
• Confined providers cannot read the Runtime coordinates file (*-runtime-coords.json) or connect to the local control listener. A test proves this.
• The did and wallet providers run with no network access and no files beyond their own store. A test proves this.
• A hostile-input test per provider (media file, IPFS block, chain RPC response, model file) runs the provider under its profile and proves it cannot read wallet or account data of others, the Runtime coordinates file or attach secret, call other providers, or reach undeclared network.
• Each provider's stdout line length is capped and its stderr goes to its own rotated log (today stdout lines are unbounded, elastos/crates/elastos-runtime/src/provider/bridge.rs:1104, and stderr goes to a runtime.log that is never rotated). Test: a 1 GB line stops that provider and the Runtime keeps running.

Browser plan reconciliation — 2026-10-08

#290/#291/#292 consume the declared confinement/key boundary for Browser Engine/Exit/native helpers. Their VM proof and opaque GUI isolation describe their own tested boundaries. Native provider rights remain governed by this issue, with exact platform refusal and hostile-input evidence. #293 verifies the combined advertised Browser boundary; full provider confinement is a shared producer result.

Local AI plan reconciliation — 2026-10-08

The Local AI consumer of the shared confinement contract is #99, after #98's resource/lifecycle result. Prove the real installed model provider, guard and engine have only their declared files, journals, device access and private Runtime channels. Pair unrelated-file/Unix-service/direct-network/control-listener/descriptor refusals with a working permitted inference request.

Distinguish preflight resource estimates from execution-time enforcement, and verify declared limits and final descendant settlement. #98/#100/#101 retain queue, engine ownership and retry semantics; #180 covers model-output attempts to request effects. Match actual manifests and target receipts rather than inferring isolation from the presence of a filter.