Expose Guardian’s current dynamic UI generation engine as an SDK

### Problem description

We have developed a National Carbon Registry (NCR) policy on Hedera Guardian, along with a custom UI tailored to that specific policy (transfer, retirement & organization support). However, we now have a requirement to extend this functionality to support other public policies on Guardian via NCR. The goal is to allow users to seamlessly interact with any selected policy using a unified, dynamic UI experience, similar to the current NCR workflow. The UI should adapt based on the policy selected at the start.

Our use case also requires additional UI features and functionalities that fall outside the scope of the built-in Guardian framework. To meet this need, we must decouple the frontend and provide a more flexible, policy-driven custom interface.

#### Proposed Solution
While Guardian currently generates UI dynamically based on the policy definition, our use case requires additional UI features and functionalities that fall outside the scope of the built-in Guardian framework. To meet this need, we propose building a custom UI layer that uses Guardian purely as the backend engine.

We suggest exposing Guardian’s dynamic UI generation engine through an SDK. This SDK would possibly handle the following:
- Communication with Guardian backend endpoints
- Policy file loading and parsing
- Generating the policy relationship graph and managing role-based permissions
- Defining step-by-step UI requirements, such as form layouts including:
- Field names
- Data types
- Default values

Using this SDK, we can render dynamic workflows in a custom UI while maintaining compatibility with Guardian's backend logic and policy structures. Guardian UI can continue to serve as the policy editor, while the custom frontend delivers an improved and extensible user experience.

### Requirements
- The rendering engine and UI generator should be decoupled from the main Guardian UI application
- Expose the rendering logic as a reusable SDK or NPM module
- The SDK should:
- Accept a Guardian policy file (JSON, YAML or .policy) as input
- Provide a way to generate UI configuration or components dynamically from the policy structure
- Allow UI components to be styled via externally provided CSS classes or themes
- Handle standard policy interactions (e.g., requestVCDocument, sendToGuardianBlock) through callbacks or bindings
- Ensure version compatibility with Guardian's core policy format and schema definitions
- Include thorough documentation and examples

### Definition of done
- The Guardian rendering engine is fully modularized and published as a separate SDK
- The SDK is independently usable in any web application and can dynamically render UIs based on Guardian policy files
- The SDK supports injecting custom CSS classes or themes per component
- Backward compatibility with existing Guardian policy files is ensured
- Clear documentation, including usage examples, component mappings, and customization options

### Acceptance criteria
- Developers can render UI from a Guardian policy file using the SDK with no dependency on Guardian's default frontend
- Developers can install the SDK and pass in a policy file to generate a UI dynamically
- Developers can override styles or bind custom CSS classes to each UI component
- The generated UI supports the same functional behavior (e.g., form submission, validation) as the default Guardian UI
- All UI components available in the default Guardian frontend are exposed through the SDK
- At least one policy workflow has been demonstrated working with the SDK in an external frontend project

Start by mapping the current Guardian dynamic UI generation engine, default frontend, backend endpoints, policy file formats, and policy schema definitions described in the issue. Determine how the rendering logic and standard interactions such as requestVCDocument and sendToGuardianBlock can be separated into an SDK. Done means an independently installable SDK can render a policy-driven workflow with theming, compatibility, documentation, and an external frontend demonstration.

Written by the indexing model from the issue text.