feat: added user-friendly storybook component

[rohanm-crest]

Issue number: ADDON-78948

PR Type

What kind of change does this PR introduce?

• Feature
• Bug Fix
• Refactoring (no functional or API changes)
• Documentation Update
• Maintenance (dependency updates, CI, etc.)

Summary

Changes

Introduced a dedicated playground for entity validation within Storybook. This update allows users to dynamically modify the input arguments of each entity and instantly validate the configuration. The main goal is to ensure that only allowed key-value pairs are used, helping to catch unknown or unsupported properties early in the development process.

User experience

With this playground in place, users can interactively experiment with entity inputs directly in Storybook. By tweaking the arguments, they can immediately see if any invalid keys are present, streamlining the debugging process and improving schema adherence. This makes the validation workflow more intuitive and efficient, reducing the chances of misconfigured entities and also reduce the efforts to build and check the entities in UI.

Checklist

If an item doesn't apply to your changes, leave it unchecked.

Review

• self-review - I have performed a self-review of this change according to the development guidelines
• Changes are documented. The documentation is understandable, examples work (more info)
• PR title and description follows the contributing principles
• meeting - I have scheduled a meeting or recorded a demo to explain these changes (if there is a video, put a link below and in the ticket)

Tests

See the testing doc.

• Unit - tests have been added/modified to cover the changes
• Smoke - tests have been added/modified to cover the changes
• UI - tests have been added/modified to cover the changes
• coverage - I have checked the code coverage of my changes (see more)

Demo/meeting:

Reviewers are encouraged to request meetings or demos if any part of the change is unclear

[soleksy-splunk]

Plus please make it 🟢 and fix title

[rohanm-crest]

I have read the Code of Conduct and I hereby accept the Terms

[rohanm-crest]

I have read the CLA Document and I hereby accept the CLA

[soleksy-splunk]

What is the reason for creating all those interfaces?

As I believe for userPlayground we can use code like this

        if (item.type === 'index') {
            const migrated = migrateIndexTypeEntity(item as IndexEntity);
            result = SingleSelectEntity.safeParse(migrated);
        } else if (item.type === 'interval') {
            const migrated = migrateIntervalTypeEntity(item as IntervalEntity);
            result = TextEntity.safeParse(migrated);
        } else {
            result = AnyOfEntity.safeParse(item);
        }

using existing zod types and elements

[rohanm-crest]

We can rely on Zod inference alone, but defining explicit TypeScript interfaces and using satisfies helps enforce stricter type alignment. This has been especially helpful in Storybook, where strict validation ensures type errors surface clearly during development.

[soleksy-splunk]

Just wondering why those interface introduction is necessary.