Show updated modules when migrating them to the new dev platform

[isaacroldan]

WHY are these changes introduced?

To improve the clarity of extension deployment information by properly categorizing extensions as "unchanged" or "updated" in the deployment prompt.

WHAT is this pull request doing?

This PR refines how extensions are categorized during deployment:

1. Adds a new unchanged field to the ExtensionIdentifiersBreakdown interface
2. Properly separates extensions that are truly being updated from those that remain unchanged
3. Updates the deployment prompt to display extensions in appropriate categories:
   • New extensions
   • Unchanged extensions
   • Updated extensions
   • Removed extensions

ONLY extensions that are being "migrated" to dev dash and adding a UID are shown as UPDATED

How to test your changes?

1. Run a deployment with a mix of new, updated, and unchanged extensions
2. Verify that the deployment prompt correctly categorizes each extension
3. Confirm that extensions being migrated to DevDash appear in the "updated" section

To force a extension to be migrated, running everything locally, delete the user_identifier from an extension in the active version in the Database.

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

[isaacroldan]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Show updated modules when migrating them to the new dev platform #6135 👈 (View in Graphite)
• Show list of added UIDs on the first deploy #6119
• Remove migrateLegacyFunctions #6111
• Send uuid on app version create to do app matching #6105
• main

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

[github-actions]

We detected some changes at packages/*/src and there are no updates in the .changeset.
If the changes are user-facing, run pnpm changeset add to track your changes and include them in the next release CHANGELOG.

Caution

DO NOT create changesets for features which you do not wish to be included in the public changelog of the next CLI release.

[github-actions]

Coverage report

St.❔	Category	Percentage	Covered / Total
🟡	Statements	77.96% (+0.01% 🔼)	13001/16676
🟡	Branches	72.14%	6339/8787
🟡	Functions	78.13% (+0.03% 🔼)	3376/4321
🟡	Lines	78.36% (+0.01% 🔼)	12308/15707

Test suite run success

3046 tests passing in 1315 suites.

Report generated by 🧪jest coverage report action from e2c3555

[github-actions]

Differences in type declarations

We detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:

• Some seemingly private modules might be re-exported through public modules.
• If the branch is behind main you might see odd diffs, rebase main into this branch.

New type declarations

We found no new type declarations in this PR

Existing type declarations

packages/cli-kit/dist/public/common/function.d.ts

@@ -1,4 +1,4 @@
-import type { DebouncedFunc, DebounceSettings, ThrottleSettings } from 'lodash';
+import type { DebouncedFunc, DebounceSettings } from 'lodash';
 /**
  * Creates a function that memoizes the result of func. If resolver is provided it determines the cache key for
  * storing the result based on the arguments provided to the memoized function. By default, the first argument
@@ -20,25 +20,11 @@ export declare function memoize<T extends (...args: any) => any>(func: T, resolv
  * Note: If leading and trailing options are true, func is invoked on the trailing edge of the timeout only
  * if the the debounced function is invoked more than once during the wait timeout.
  *
- * See David Corbacho's article for details over the differences between _.debounce and _.throttle.
+ * See David Corbacho’s article for details over the differences between _.debounce and _.throttle.
  *
  * @param func - The function to debounce.
  * @param wait - The number of milliseconds to delay.
  * @param options - The options object.
  * @returns Returns the new debounced function.
  */
-export declare function debounce<T extends (...args: any) => any>(func: T, wait?: number, options?: DebounceSettings): DebouncedFunc<T>;
-/**
- * Creates a throttled function that only invokes func at most once per every wait milliseconds.
- * The throttled function comes with a cancel method to cancel delayed invocations and a flush method to immediately invoke them.
- * Provide an options object to indicate whether func should be invoked on the leading and/or trailing edge of the wait timeout.
- * Subsequent calls to the throttled function return the result of the last func invocation.
- *
- * See David Corbacho's article for details over the differences between _.debounce and _.throttle.
- *
- * @param func - The function to throttle.
- * @param wait - The number of milliseconds to throttle invocations to.
- * @param options - The options object.
- * @returns Returns the new throttled function.
- */
-export declare function throttle<T extends (...args: any) => any>(func: T, wait?: number, options?: ThrottleSettings): DebouncedFunc<T>;
\ No newline at end of file
+export declare function debounce<T extends (...args: any) => any>(func: T, wait?: number, options?: DebounceSettings): DebouncedFunc<T>;
\ No newline at end of file