[WIP] Analyze meshspaces shell/runtime API and lifecycle contract

[Copilot]

Thanks for asking me to work on this. I will get started on it and keep this PR's description up to date as I form a plan and make progress.

---

This section details on the original issue you should resolve

<issue_title>[Copilot Planning] Meshspaces shell/runtime API and lifecycle contract gap analysis</issue_title>
<issue_description>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.</issue_description>

<agent_instructions>This is a planning and review task, not a Meshspaces implementation task. Work against the repository as it exists today. Prefer findings reports, doc updates, edge-case analysis, and concrete API/UI/permission recommendations over product code changes. Do not start building Meshspaces. Prioritise privacy, security, onboarding, wrong-target risk, migration safety, and explicit per-mesh targeting requirements.</agent_instructions>

Comments on the Issue (you are @copilot in this section)