Keep built-in extensions visible in Extensions gallery after install

[Copilot]

Built-in extensions were being removed from the Extensions gallery after being added to a project, while third-party extensions remained discoverable. This change aligns gallery behavior so bundled and third-party extensions are treated consistently after installation.

• Behavior fix

  • Removed the dependency-based exclusion for bundled extensions in the gallery source list.
  • Built-in extensions (e.g., Servo) now remain visible in the Extensions page after being added.

• Implementation

  • Updated webapp/src/extensionsBrowser.tsx in fetchBundled().
  • Deleted the filter that hid bundled packages when they already existed in pkg.mainPkg.deps.

• Resulting UX

  • Users can re-open Extensions and still see built-in entries they previously installed, matching current third-party extension behavior.

// removed from fetchBundled()
.filter(pk => !pkg.mainPkg.deps[pk.name] || pkg.mainPkg.deps[pk.name].cppOnly)

[abchatra]

Fixes microsoft/pxt-microbit#6974

[jwunderl]

Is showing built in extensions that are added the way we wanted to go? I would think better to not show the extension that has already been added, as it's a bit confusing what it would do -- update extension, remove extension, nothing, etc? (at first read that's how I perceived the issue as well since the 3rd party extension was in the 'but' portion, but on second read I'm not sure either way was pushed much just that there is a difference)

[abchatra]

I thought about it. But in my opinion, ideally, we should keep the extension in the gallery and add a tick mark that it is already installed (similar to app store in iOS) which is a next step.

[Jaqster]

Could we do a similar treatment to how we indicate Experiments are on or off?

[jwunderl]

put up #11442 continuing this but with the ribbons, closing in favor of that