Evaluate dephpend for dead-code and unused-code analysis

[coisa]

Problem

dependencies already flags missing/unused/misplaced packages, but it does not perform PHP-level dead-code checks.

dephpend can complement dependency and architecture checks by identifying dead code, type usage, and refactoring opportunities missed by composer-level analysis.

Proposal

Evaluate integrating dephpend in a dedicated optional analysis command path before any default CI adoption.

Potential implementation:

• Add optional command execution with optional --dephpend flag inside an existing or new analyse command.
• Default to reporting mode with stable exit semantics.
• Respect local configuration or fallback to packaged defaults.

Goals

• Identify high-confidence dead-code candidates across projects using consistent output handling.
• Avoid making dependencies command execution slower by default.
• Keep false-positive-prone checks off by default with explicit opt-in.

Expected Benefits

• Reduced maintenance burden in large repos by surfacing stale code paths.
• Better signal for dependency-health follow-up and technical debt cleanup.

Why Not (if skipped)

• High false-positive rate in dynamically accessed code.
• Potentially expensive scans on codebases with large runtime-generated patterns.

Non-goals

• Replacing composer/dependencies analysis.
• Enforcing strict blocking policy without baseline support.

Acceptance Criteria

• Issue documents a clear opt-in strategy and expected command cost.
• Execution path is deterministic and isolated from dependency command failures.
• Docs explain how to disable or tune noisy rules locally.

Architectural / Isolation Criteria

• MUST: The orchestration path isolates process building from analysis interpretation.
• MUST: Report rendering remains independent from artifact writes.
• MUST: Exit behavior and JSON output options are deterministic.