### Check existing issues - [x] I've verified that this request isn't described by any existing issues. ### Request Snaps should filter out libraries that are included in content snaps, similar to how libraries included in base snaps are filtered. This should be an opt-in mechanism for existing bases and opt-out for new bases. ### The problem it solves Content snaps, such as [gnome](https://github.com/ubuntu/gnome-sdk/tree/gnome-46-2404), [kde](https://invent.kde.org/neon/snap-packaging/kf6-core-sdk/-/tree/work.core24), and [mesa](https://github.com/canonical/mesa-2404), ship with a large set of libraries. Snaps using these content snaps often package duplicates of libraries included in the content snap. This results in larger snap sizes and a higher risk of using outdated libraries. [Many users](https://github.com/search?q=path%3Asnapcraft.yaml%20%22cleanup%3A%22&type=code) include a cleanup part to remove duplicated libraries. The [snapcrafters](https://forum.snapcraft.io/t/reducing-the-size-of-desktop-snaps/17280) and [content snap maintainers](https://canonical-ubuntu-frame-documentation.readthedocs-hosted.com/how-to/use-snap-graphics-on-base-core24/#using-the-helpers-provided) document this pattern. This cleanup part is common enough that Snapcraft should provide in-house support. ### Research needed This will require some research to decide: - Syntax in snapcraft.yaml. - Default behavior for core26. - Whether to support all content snaps or a curated list of "stable" content snaps. - We have to assume that the content snap at build-time will have the same set of libraries as the content snap installed on a user's system. - How to implement: Should it be a part added by the extensions? Or a post-prime step?