epic(install): install-hardening pass — installer leaves user in fully working state

[jaylfc]

Umbrella issue tracking the install-hardening principle (memory note).

The bar: install script finishes, taOS works fully without the user having to apt install or otherwise intervene. Today's install gets the user to a running service but leaves multiple silent failures depending on platform and what nice-to-haves are missing.

Concrete gaps already filed

• bug(hardware): runtime Vulkan detection misses iGPUs when vulkan-tools not installed #354 — runtime Vulkan detection misses iGPUs without vulkan-tools installed (install-server.sh should pull vulkan-tools + mesa-vulkan-drivers when an Intel iGPU is detected)
• bug(install): install-server.sh detects RKNPU but never runs install-rknpu.sh after clone #359 — install-server.sh detects RKNPU but never runs install-rknpu.sh after clone
• bug(install-rknpu): librknnrt version detection returns empty after successful download #360 — librknnrt version detection returns empty after successful download
• feat(rk3588): Performance mode toggle in Settings (RK3588-only) for full-throttle inference #361 — RK3588 Performance mode toggle (governor + taskset baked into the rk-llama.cpp service)
• (this PR series) — hardware.json cache prevents re-probe; disk quota monitor "still work" lie; container backend unconfigured RuntimeError

Pattern

Every one of those is the same shape: taOS detects something but doesn't fully wire it up, OR depends on a host-side dependency we should be bundling, OR has a "still works" fallback that doesn't actually fall back.

Acceptance for this epic

Install on each supported target should produce a system that:

1. Has every dependency taOS uses already present (no manual apt install step)
2. Has every nice-to-have for capability detection installed (vulkan-tools, rocm-smi, nvidia-smi, etc. for the relevant accelerator)
3. Has the right container backend (Incus by default on Linux; Docker on macOS) auto-installed
4. Has prebuilt binaries fetched and verified for the target SoC (RK3588 librknnrt + rkllama, Apple Silicon MLX builds, etc.)
5. Reports "ready" only when every claimed capability has been verified to actually work — not just detected on paper

Per-platform audit

Need to audit and confirm per platform:

• Orange Pi 5 / RK3588 — librknnrt + rkllama + rk-llama.cpp + RK3588 perf mode (feat(rk3588): Performance mode toggle in Settings (RK3588-only) for full-throttle inference #361 covers the perf piece). Prebuilt binaries on the HF mirror.
• Raspberry Pi 5 / BCM2712 — currently NOT supported. Either add support or be explicit that the install script declines.
• x86 Linux + Intel iGPU — vulkan-tools + mesa-vulkan-drivers + Incus. Auto-install all three.
• x86 Linux + NVIDIA GPU — CUDA runtime + nvidia-smi. Confirm install-server.sh handles the CUDA dependency or at least flags it loudly.
• x86 Linux + AMD GPU — ROCm install path. Currently script logs a warning; needs to either auto-install ROCm or flag clearly that it's a manual prereq.
• Apple Silicon Mac — Apple Containerization framework, MLX runtime. Per memory we ship a .app bundle, so different install path. Audit separately.

Each of these should be its own follow-up child issue under this epic once the per-platform owner has eyes on it.

Why now

Two real testers (@johny-mnemonic and @redkjuegos) have hit install-time issues that should never have reached them. Each failure is small but the cumulative friction is "this is hard to set up." Fixing the pattern, not just each instance, is the right return on time.