Add a doctor command for repository readiness diagnostics

[coisa]

Problem

Fast Forward DevTools now bootstraps and validates a broad set of repository concerns: tests, docs, reports, changelog automation, workflow stubs, wiki setup, packaged skills, packaged agents, funding metadata, and synchronized GitHub defaults. When something is missing or misconfigured, maintainers usually discover it only after a specific command fails or a workflow breaks.

That makes onboarding and support more reactive than they need to be. The product is now broad enough that it needs a dedicated readiness audit entrypoint.

Proposal

Add a doctor command that inspects the current repository and reports whether the local setup and consumer-facing automation are ready, drifted, or missing required prerequisites.

Goals

• Provide one command to audit repository readiness.
• Surface actionable diagnostics before maintainers run the full toolchain or push a broken workflow.
• Reduce support overhead by turning common setup mistakes into explicit, guided findings.

Expected Behavior

A maintainer should be able to run composer dev-tools doctor and receive a structured summary of important repository concerns, such as missing config files, stale synchronized assets, broken packaged links, missing wiki setup, changelog workflow prerequisites, and other high-value readiness checks.

Implementation Strategy

1. Define a reusable diagnostic model with statuses, messages, and optional remediation hints.
2. Start with a focused set of high-value checks instead of trying to inspect everything in the first pass.
3. Group diagnostics by concern, such as local tooling, synchronization drift, changelog/release readiness, and generated-output expectations.
4. Keep console rendering separate from diagnostic collection so the command can later support structured output.
5. Document common usage in README and docs.

Scope

• New doctor command surface.
• Reusable diagnostics abstraction and renderer.
• Initial checks for the most common local and consumer-facing setup failures.

Non-goals

• Do not auto-repair findings in the first version.
• Do not replicate the full execution logic of existing commands.
• Do not block future expansion by overfitting the first implementation to one repository layout.

Acceptance Criteria

Functional Criteria

• composer dev-tools doctor exists and reports readiness findings with deterministic output.
• The initial implementation covers a practical baseline of local and consumer-facing checks.
• Findings distinguish clean state, warnings, and failures clearly.
• Each failing or warning diagnostic includes enough context to guide the next action.
• Focused tests cover representative clean and failing scenarios.
• README and docs document the new command and its intended use.

Architectural / Isolation Criteria

• MUST: The core logic MUST be isolated into dedicated classes or services instead of living inside command or controller entrypoints.
• MUST: Responsibilities MUST be separated across input resolution, domain logic, processing or transformation, and output rendering when the change is non-trivial.
• MUST: The command or controller layer MUST act only as an orchestrator.
• MUST: The implementation MUST avoid tight coupling between core behavior and CLI or framework-specific I/O.
• MUST: The design MUST allow future extraction or reuse with minimal changes.
• MUST: The solution MUST remain extensible without requiring major refactoring for adjacent use cases.
• MUST: Argument and option resolution MUST be validated separately from command execution logic.
• MUST: Console formatting and rendering MUST stay separate from domain processing.
• MUST: Exit behavior, error messaging, and generated output MUST remain deterministic and testable.