Add snapshot validation step before processing in migration/export flow

[sachin9058]

Summary

This issue proposes adding a lightweight validation step for snapshot data before it is processed or transformed in the migration/export pipeline.

The goal is to ensure that input data is structurally valid and consistent before any transformation logic is applied.

---

Background & Motivation

In the Fabric → Fabric-X migration flow, snapshot data is used as the source of truth for reconstructing ledger state.

This data is expected to follow a structured format:

• Channel → Namespace → Key-Value

Before transforming this into Fabric-X’s namespace-based model, it is important to ensure that the input snapshot data is valid.

Currently, there is no explicit validation step to check for malformed or inconsistent snapshot structures. This can lead to:

• silent data inconsistencies
• runtime failures during transformation
• harder-to-debug issues downstream

---

Problem

Without validation, the system assumes that snapshot data is always well-formed. However, potential issues may include:

• Empty or missing namespaces
• Empty keys or invalid key entries
• Duplicate keys within a namespace
• Unexpected or inconsistent data structures

These issues can propagate into later stages (export, bootstrap), making them harder to detect and fix.

---

Proposed Solution

Introduce a minimal validation layer that runs before snapshot data is processed.

This validation should:

• Ensure namespaces are non-empty
• Ensure each namespace contains valid key-value entries
• Detect empty or invalid keys
• Detect basic structural inconsistencies

The validation should return clear and actionable errors when invalid data is detected.

---

Scope (Intentionally Minimal)

• Add a validation helper function (e.g., ValidateSnapshot)
• Validate basic structural correctness only
• Add unit tests covering edge cases

This does NOT include:

• Full schema validation
• Performance optimizations
• Changes to public APIs
• Integration with all pipeline stages (can be added later)

---

Example

Input:

{
  "channel": "mychannel",
  "namespaces": {
    "asset": {
      "a1": "value1",
      "a2": "value2"
    }
  }
}

Invalid cases:

• Empty namespace name
• Namespace with no keys
• Empty key ("")
• Missing namespace block

---

Expected Outcome

• Early detection of invalid snapshot data
• Improved robustness of migration pipeline
• Clear error messages for debugging
• Safer foundation for future exporter/bootstrap work

---

Why This Matters

This validation step acts as a guardrail before transformation logic. It helps ensure correctness and reduces the risk of propagating invalid state into downstream components.

It is particularly useful in the context of the LFDT migration workflow, where correctness of state transformation is critical.

---

Proposed Next Steps

• Implement minimal validation helper
• Add unit tests for edge cases
• Integrate validation step before transformation logic (optional follow-up)

---

I’d be happy to start with a minimal implementation and refine it based on feedback.