[CoR] Gate local plan approval on container runtime readiness

[nturinski]

Problem

The prerequisite guidance checks docker info or podman info, and debug generation later blocks when the selected container engine is not running. However, the plan UI does not expose runtime readiness as a blocking condition. A user can approve a local-development plan after installing Docker Desktop even though the engine is not yet usable, leading to an avoidable failure during execution or after session resume.

Proposed work

• Represent container runtime readiness separately from installation state using explicit values such as ready, notReady, and unknown.
• Record the selected runtime and readiness in structured plan/prerequisite data rather than relying on prose notes.
• Show a prominent remediation banner when the runtime is explicitly not ready.
• Disable plan approval for notReady and reuse the existing Re-check prerequisites action.
• Keep unknown visible but non-blocking because sandboxed probes can produce false negatives; require clear confirmation if product policy calls for stronger gating.
• Ensure resumed sessions retain and render the readiness state correctly.

Likely implementation surfaces include:

• resources/agents/shared-references/prerequisites.md
• resources/agents/azure-debug-plan/references/plan-template.md
• src/webviews/copilotOnRails/views/utils/parseLocalDebugPlanMarkdown.ts
• src/webviews/copilotOnRails/views/LocalPlanView.tsx
• src/webviews/copilotOnRails/views/ScaffoldPlanView.tsx
• test/copilotOnRails/parseLocalDebugPlanMarkdown.test.ts

Acceptance criteria

• An installed but stopped/unusable Docker or Podman runtime is represented as notReady.
• A plan with notReady cannot be approved until a successful re-check.
• unknown is distinguished from a confirmed failure and does not silently appear ready.
• The UI gives actionable recovery guidance without burying it in plan notes.
• Tests cover ready, not-ready, unknown, re-check, and resumed-session behavior.