v0.8: docs/LIFE_RUNTIME_STANDARD.md update — 5-stage assembly + Provider Registry

[devin-ai-integration]

This sub-issue tracks the v0.8 update to docs/LIFE_RUNTIME_STANDARD.md — the
authoritative runtime protocol — replacing the v0.7 8-step load sequence with
the cleaner 5-stage assembly pipeline and adding the Provider Registry concept.

This is the final sub-issue in the v0.8 epic; it depends on Binding (#N4) and
Tier (#N5) being merged first because the pipeline reads both.

Scope

• Update: docs/LIFE_RUNTIME_STANDARD.md — replace 8-step load sequence with 5-stage assembly pipeline; add Provider Registry, LifeCapabilityProvider interface, sandbox levels, OS bootstrap, hosted-vs-offline rules
• Update: examples/minimal-life-package/README.md — show how the package would launch under v0.8 runtime
• New tests: lightweight sanity tests for Provider Registry layout (no real provider implementation in this PR)
• CHANGELOG.md v0.8 Draft entry

5-stage assembly pipeline (replaces v0.7 8-step)

1. Verify — sha256 + JSON Schema + signature + expiry + lifecycle_state + withdrawal ping + audit chain
2. Resolve — read binding.capabilities + tier; consult Provider Registry; tier-driven graceful degradation (low tier auto-fallback, high tier strict-or-refuse)
3. Assemble — instantiate providers, inject hard_constraints, inject disclosure label, emit capability_bound audit event
4. Run — start surface; filter inputs/outputs by forbidden_uses[]; prefix outputs with disclosure label
5. Guard — withdrawal watcher (≥24h ping); memorial watcher; expiry watcher; audit emitter

Provider Registry & interface

• ~/.dlrs/providers/<provider_name>/ directory layout
• Provider classes:
  • built-in — shipped with runtime; trusted; OS process
  • user-installed — installed via lifectl / OS package manager; trusted; OS process
  • .life-bundled — disallowed in v0.8 (per Topic 4 D2)
• Interface signature (normative): LifeCapabilityProvider { capability, name, version, engine_compatibility_id, supports(binding), load(asset_paths, binding) → instance, teardown(instance) }

Decisions referenced

• D1 = C: graded sandbox (built-in / user OS-process; bundled MUST be sandboxed or refused)
• D2 = B (v0.8) + C (v1.0+): no bundled provider code in v0.8; trusted issuer whitelist in v1.0+
• D3 = Hybrid: pure-cloud .life acceptable; offline recommended not mandatory; both first-class; default per-user
• D4 = C: three-field surface (supported[] + preferred + minimum_required)
• D5 = C: bootstrap via OS package manager; .life carries no installer code

(See docs/LIFE_ASSET_ARCHITECTURE.md topic 4 for full rationale.)

Acceptance criteria

• docs/LIFE_RUNTIME_STANDARD.md reflects 5-stage pipeline (8-step section removed or marked superseded)
• Provider Registry layout, classes, and interface signature are normative
• Sandbox rules are normative (D1)
• Bundled-provider prohibition (v0.8) is explicit (D2)
• Hosted-vs-offline rules (D3) are normative including AND-gate cross-reference to Binding D5
• Surface field semantics (D4) cross-reference Binding spec
• OS bootstrap policy (D5) is documented
• examples/minimal-life-package/README.md updated to reflect v0.8 launch flow
• CHANGELOG.md v0.8 Draft entry
• CI green

Parent epic: see top of #N1.