feat: unify async OS HAL, profiling, symbolization, and allocator instrumentation

[zackees]

Context

kernal-api is the stable systems facade for zccache, Soldr, and fbuild. The dependency graph is intentionally one-way:

zccache / soldr / fbuild -> kernal-api -> running-process -> Tokio/native OS

running-process is the trusted native/process substrate and must never depend on kernal-api. kernal-api owns semantic application contracts and privately adapts backend types. Client applications ultimately use neither running-process nor Tokio directly.

The canonical design is documented in ARCHITECTURE.md.

Proposal

Build out facade-owned capability modules for:

• async runtime handles, cancellation, tasks, progress/connection timeouts, and diagnostics;
• bounded process execution, child containment, kill-on-drop, and detached launch;
• BLAKE3 file/content hashing;
• broker identity, endpoint, frame, route, error, service-definition, and manifest semantics backed initially by running-process;
• allocation, crash capture, CPU/off-CPU profiling, symbolization, filesystem, mapped files, locks, networking, HTTP services, SQLite, and GUI hosting as justified by real client migrations.

Facade types describe intent and safety policy rather than backend vocabulary. Defaults must be bounded, cancellable, observable, and safe for slow-progress connections.

Migration

1. Add the facade gaps required by zccache.
2. Rebase zccache embedded async/cancellation APIs.
3. Move process launch, bounded probing, detached deployment, identity, and hashing.
4. Move broker access behind compatibility adapters without changing bytes, version negotiation, endpoints, or round-trip count.
5. Remove all direct zccache running-process dependencies and enable the strict boundary Dylint.
6. Repeat for Soldr and fbuild.

The broker daemon implementation remains in running-process during phase 1. After all three consumers stabilize, hoist the generic broker-daemon pattern into kernal-api as a managed-service capability while leaving application payload protocols with their applications.

Acceptance criteria

• RED -> GREEN tests cover every new public capability and its failure semantics.
• The resolved dependency graph contains no running-process -> kernal-api edge.
• Public API may re-export the approved canonical running-process contract under kernal-api names (see feat: re-export canonical running-process Inherited and Independent spawn API #189/refactor: audit duplicated running-process APIs and plan canonical re-exports #196); unrelated Tokio/native implementation details remain private.
• Disabled optional features omit their heavy dependency trees.
• Client compatibility tests prove process lifecycle, timeout, cancellation, and broker behavior are preserved.
• zccache, Soldr, and fbuild release with no direct running-process dependency after their migrations.
• The Dylint rejects normal, aliased, target, build, and test dependencies on facade-owned implementations.

Decisions

• running-process is the base layer; kernal-api is the higher facade.
• There is no kernal-api-base and no reverse dependency.
• Use direct namespace re-exports/aliases for approved canonical running-process APIs, preserving exact Rust type identity. Do not maintain matching facade enums or conversion tables for equivalent contracts. refactor: audit duplicated running-process APIs and plan canonical re-exports #196 audits existing duplicates; real semantic differences require explicit treatment.
• Broker ownership moves later and does not block the first migration.
• One supported API does not mandate one compilation unit. Crate splits or release amalgamation require reproducible compile-timing evidence.
• Do not create speculative data traits or implementation crates without multiple real backends.

Open questions

• Which exact capability slice yields the best first clean/incremental build-time improvement?
• Which running-process operations need narrowly scoped additions before private facade adapters can preserve behavior?

Related issues

• refactor: define running-process as the native substrate for kernal-api running-process#1143 defines the native-substrate work.
• refactor: migrate zccache completely from running-process to kernal-api zccache#1518 defines the first complete client migration.
• perf: benchmark kernal-api compilation boundaries and release packaging #3 measures implementation/package boundaries without changing this architecture.

Active implementation coordination

The user has authorized completing this umbrella together with running-process#1202, #189 and #196. For equivalent running-process APIs, direct Rust re-exports and namespace aliases now supersede the older blanket facade-owned-type prohibition. All migration, protocol, lifecycle, feature-isolation, downstream-release and verification requirements remain in scope; this note does not claim they are completed.

Dependency edits use a temporary git checkout under _vender/<dependency>/ for integration. Publish and wait for the new dependency release, then remove temporary checkout/path patches and select its exact public version. Per user instruction, implementation and test authoring across repositories precede the build/lint/test phase.