docs: add refactor plan for error kind classification strategy

This refactor plan addresses the complexity in error classification by
moving error kind determination into the error types themselves through
the Traceable trait, eliminating manual classification in command code.

Context:
- Error kinds were introduced to provide quick error classification
  without parsing detailed trace files (commit 635ef9e)
- Currently each command manually classifies errors via pattern matching
- Command-specific ErrorKind enums exist but are inconsistent
- Some variants are never used (ConfigureErrorKind::CommandExecutionFailed)

Proposal (Recommended):
- Create single unified ErrorKind enum with 7 generic categories
- Add error_kind() method to Traceable trait
- Each error type self-describes its category
- Remove command-specific ProvisionErrorKind and ConfigureErrorKind
- Eliminates manual classification in build_failure_context()

Benefits:
- Simpler architecture with one enum for all commands
- Self-describing errors (no reverse engineering)
- Consistent categorization vocabulary
- Easy to extend with new commands
- Foundation for future retry/recovery strategies

Implementation:
- 8 detailed phases covering trait extension, error implementations,
  context updates, command modifications, and test updates
- Breaking change to state JSON (acceptable in PoC phase)
- Progress tracking table included

Alternatives Considered:
- Command-specific kinds + type erasure (too complex)
- Associated types (breaks object safety)
- Remove error kinds entirely (loses useful categorization)

See: docs/refactors/error-kind-classification-strategy.md

Author: josecelano