Store history restore for state transition

What does this MR do and why?

Store history restore for state transition

Implementation Changes:

• Updated JSON Schema - Added state_history array field (max 5 items) to namespace_detail_state_metadata.json
• State History Tracking - Modified Stateful concern to:
  • Track previous states in state_history (keeps last 5 states)
  • Automatically record state before each transition
  • Prevent duplicate consecutive states
• Restore Functionality - Added public restore(options = {}) method that:
  • Restores namespace to its previous state from history
  • Supports step-by-step restoration through state chain
  • Updates metadata and logs restoration events
  • Works with user attribution and correlation IDs

Implementation

Problems with transition :restore approach:

1. The state machine can't dynamically determine where to restore to; it would need every possible combination hardcoded
2. The destination state comes from state_history.last, which the state machine can't access during event definition
3. before_transition guards (like validate_ancestors_state) would run and might block legitimate restores
4. Every time you add a new state, you'd need to update the restore event transitions

The current approach is better because:

1. restore bypasses the state machine intentionally
2. It's essentially a manual override that directly manipulates the state
3. It has its own logging and metadata handling
4. It's more flexible - it can restore to any previous state without declaring all combinations

References

Closes #583196

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.