Support intents for ui extensions

[vividviolet]

WHY are these changes introduced?

This change modernizes the UI extension asset handling system by replacing the legacy build_manifest approach with a new manifest.json-based system that supports additional asset types including intents.

Related https://github.com/shop/issues-admin-extensibility/issues/2274

WHAT is this pull request doing?

• Adds support for intents field in extension point schemas with type, action, schema, name, and description properties
• Adds Intents to the AssetIdentifier enum for asset handling
• Updates UI extension build pipeline to use include_assets step instead of copy_static_assets, with support for tools, instructions, and intent schemas
• Refactors extension payload generation to read from manifest.json instead of build_manifest, enabling better asset tracking with source file timestamps
• Implements specialized handling for intents assets that transforms them into extension point-level properties with schema asset references
• Updates tests to use the new manifest.json approach and adds comprehensive test coverage for intents, tools, and instructions assets

How to test your changes?

1. Create a UI extension with intents configuration in the extension points
2. Build the extension and verify manifest.json is generated with the correct asset references
3. Test the dev server payload includes properly formatted intents with schema asset URLs
4. Verify that tools and instructions assets are correctly handled through the new manifest system
5. Confirm that asset timestamps reflect source file changes rather than build output timestamps

Measuring impact

How do we know this change was effective? Please choose one:

• n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes

[vividviolet]

• Support assets for admin links app intents #7132
• Support intents for ui extensions #7134 👈 (View in Graphite)
• Add manifest generation to include_assets build step #7016 : 1 other dependent PR (#7017 )
• Refactor extension build process to use modular build steps #6867 : 3 other dependent PRs (#6868 , #6869 , #7027 )
• Add client steps implementation to support existing functionalities #6966 : 1 other dependent PR (#6941 )
• Create abstract client steps infrastracture to externalize the ap modules client configurations #6965
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[isaacroldan]

we need to find a better way to do this, @alfonso-noriega it makes sense for dev to execute this missing steps. Wonder how much we gain from having a custom esbuild for dev (in theory is faster because it uses contexts and only rebuilds what changed, not the whole extension)

[isaacroldan]

I have an agent working on this, will have an independent PR solving this on monday morning

[vividviolet]

Thank you so much Isaac!