[Copilot Planning] Meshspaces shell/runtime API and lifecycle contract gap analysis #53

Context: The UI and operational plan cannot be implemented cleanly unless the shell/runtime contract is explicit. This issue is planning-only.

Goal: Identify the API endpoints, health signals, lifecycle states, diagnostics, and event contracts that a Meshspaces shell would need from child runtimes.

Focus areas:

• start/stop/restart semantics
• health/readiness and degraded/crashed states
• runtime diagnostics needed by shell UI
• registry/metadata shape for meshspaces
• port/origin assignment and conflict handling
• shell-safe summaries vs forbidden content exposure
• any current gaps in status/event APIs that would block implementation

Expected deliverable:

• Open a PR from a Copilot branch with a report in docs/meshspaces-review/api-and-lifecycle-contract.md
• Optionally add doc stubs/checklists for future implementation, but do not implement the APIs.

Ground rules:

• No new supervisor implementation.
• Focus on contract definition, required states, and missing diagnostics.
• Keep recommendations compatible with process-per-meshspace v1 assumptions.