[K0][OS-03] Rust-kernel architecture and reuse assessment

Programme: #1
Epic: #34

## Objective
Define the standalone Rust-kernel programme based on concrete product/isolation requirements and realistic browser/GPU/inference/application compatibility, not on language preference alone.

## Scope
- Select initial CPU/firmware/reference hardware targets.
- Compare routes: new Rust kernel, Redox reuse/contribution, Linux/Rust-heavy distribution, Asterinas/other compatibility-oriented approaches where technically relevant.
- Choose/evaluate kernel architecture: capabilities, process model, address spaces, IPC, scheduler, filesystem/network abstractions and driver model.
- Define user/kernel ABI and compatibility strategy for required browser/model/toolchains.
- Inventory graphics, storage, networking, USB, audio, input, power and accelerator dependencies.
- Define secure boot/update/recovery requirements and threat boundary.
- Keep AI inference/UI generation unprivileged user-space work.
- Produce staffing/funding/maintenance plan separate from browser runtime delivery.

## Decision rules
- Kernel work must solve a named systems/security/product requirement or advance an intentional OS research programme; it is not the next UI milestone.
- Reuse is preferred where it materially reduces driver/browser/inference burden without violating target architecture.
- Unknown compatibility work is explicitly costed/risked rather than assumed away.

## Acceptance criteria
- [ ] Architecture decision names target CPU/firmware/reference hardware and required device classes.
- [ ] Browser/rendering and local-inference compatibility paths are explicit, including required ABI/runtime/toolchain work.
- [ ] Kernel/user-space privilege boundary keeps model reasoning and generated UI outside kernel privilege.
- [ ] Driver, GPU, power, accessibility and application-compatibility gaps are listed with owners/experiments.
- [ ] Reuse/new-kernel alternatives are compared against measurable criteria and documented tradeoffs.
- [ ] K1 entry criteria, separately staffed ownership and long-term security/update maintenance obligations are approved.

## Dependencies
- CORE-01
- SEC-01

**First phase:** K0
**Maturity target:** K0 decision gate
**Owner:** os-systems

Start by reviewing the requirements in CORE-01 and SEC-01, then assess the listed kernel, compatibility, hardware, driver, security, and maintenance questions. Produce the K0 architecture decision with explicit targets, alternatives, tradeoffs, gaps, ownership, K1 entry criteria, and approval of long-term obligations.

Written by the indexing model from the issue text.