Add check and dry-run support for skills, agents, and wiki synchronization

[coisa]

Problem

skills, agents, and wiki are important parts of the consumer synchronization story, but they do not currently expose non-destructive verification paths comparable to the rest of the sync surface. The architecture docs already call out that dev-tools:sync --dry-run, --check, and --interactive skip those flows because they do not yet support safe auditing.

That creates a real product gap:

• CI cannot fully verify consumer synchronization without mutating the repository.
• maintainers cannot audit whether packaged links or wiki state are stale before writing changes.
• dev-tools:sync behaves inconsistently across synchronized resources.

Proposal

Add non-destructive check and dry-run support for the skills, agents, and wiki synchronization flows, then wire that support into dev-tools:sync so the full consumer bootstrap surface can be audited safely.

Goals

• Let maintainers verify packaged skills, packaged agents, and wiki setup without mutating the checkout.
• Make dev-tools:sync --check and --dry-run reflect the full synchronized surface.
• Keep verification output deterministic and suitable for local use and CI.

Expected Behavior

A repository should be able to run composer skills --check, composer agents --check, composer wiki --check, or composer dev-tools:sync --check and learn exactly what is missing, stale, broken, or misconfigured without creating links, editing files, or initializing submodules.

Implementation Strategy

1. Introduce a reusable verification model for packaged-link synchronization and wiki setup.
2. Teach skills and agents to report missing directories, broken symlinks, missing packaged entries, and preserved local directories in non-destructive modes.
3. Teach wiki to verify target-path expectations and submodule state without mutating the repository.
4. Integrate the new result handling into dev-tools:sync so check/dry-run modes no longer need to skip those flows.
5. Document the new behavior in command and sync guides.

Requirements

• skills, agents, and wiki MUST support non-destructive verification paths.
• dev-tools:sync --check and --dry-run MUST include those flows.
• Exit codes MUST distinguish clean and drifted states consistently.
• Output MUST clearly identify the exact missing, broken, or skipped items.

Non-goals

• Do not redesign the normal mutating behavior of these commands.
• Do not force destructive repair during check or dry-run execution.
• Do not bundle unrelated sync-architecture refactors into this issue.

Benefits

This closes one of the remaining product inconsistencies in DevTools sync behavior and makes consumer-repository auditing much safer for CI, bots, and maintainers.

Acceptance Criteria

Functional Criteria

• composer skills --check and composer skills --dry-run report link drift without mutating the checkout.
• composer agents --check and composer agents --dry-run report link drift without mutating the checkout.
• composer wiki --check and composer wiki --dry-run verify expected wiki state without initializing or modifying the submodule.
• composer dev-tools:sync --check and --dry-run include skills, agents, and wiki verification instead of skipping them.
• Focused tests cover clean, drifted, and broken-link cases plus wiki verification behavior.
• README and docs are updated where command behavior changes.

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.
• MUST: Data gathering or transformation MUST be isolated from filesystem writes or publishing steps.
• MUST: Generated output ordering and formatting MUST remain deterministic across runs.
• MUST: Re-running the workflow MUST be idempotent or clearly bounded in its side effects.