feat(cli) : add system doctor command with shared memory feature

[Harsh-Sahu43]

Summary

This PR introduces the initial implementation of the dora system doctor command, focusing on shared memory validation for Linux systems.

Dora relies on /dev/shm for inter-process communication. Incorrect permissions (expected 1777) can lead to runtime issues when spawning or coordinating nodes. This command validates the shared memory configuration and provides actionable fix suggestions when misconfigured.

This addresses (#1211).

What This PR Implements

• Adds new CLI command: dora system doctor
• Linux-only shared memory validation:
  • Verifies /dev/shm exists
  • Ensures it is a directory
  • Validates permissions are 1777 (sticky bit enabled)
• Clear CLI output:
  • ✓ when configuration is correct
  • ⚠ with fix suggestion when misconfigured
• Returns non-zero exit code if an issue is detected
• Gracefully skips the check on non-Linux platforms

Scope & Rationale

The original issue (#1211) proposes multiple diagnostic checks (toolchains, ports, config integrity, etc.).

To keep the implementation incremental and well-scoped, this PR introduces a runtime-level diagnostic focused on shared memory only.

Example Output

$ dora system doctor

⚠ Shared memory: Incorrect permissions (expected 1777)
  → Run: sudo chmod 1777 /dev/shm

[phil-opp]

Thanks for the PR!

Is it really common that /dev/shm have the wrong permissions? I don't remember any issue or bug report about this. If it's not common, I don't think that it's worth creating an extra CLI command just for checking this...

@ZhangHanDong You opened the issue at #1211 that this PR is trying to fix. Is this check what you had in mind? Do you know whether shmem permissions are really an issue in practice?

[Harsh-Sahu43]

Thanks for the clarification.

Given that /dev/shm permission issues don’t seem to be a common real-world problem, I agree that introducing a standalone system doctor command just for this check may not be justified.

Looking back at #1211, some proposed checks (e.g. toolchains, dependency versions) would require knowing which languages are actually used, likely via a dataflow.yml. Without that context, the command wouldn’t be able to determine what to validate.

@ZhangHanDong Could you clarify the intended scope of system doctor?

@phil-opp From your perspective, what would meaningfully justify a system doctor command? Should it focus only on Dora’s own prerequisites, or broader environment validation?

If the scope isn’t clearly defined yet, I’m also fine pausing or reworking this once the direction is clearer.