[Hyphaed]

Problem

Add Water already lists Waterfox (and CachyOS Browser) in FirefoxPack
and the Flatpak manifest already grants the sandbox permissions for it,
but on a machine with more than one Firefox-family browser installed,
Automatic Discover only ever shows profiles from one browser , the
first FirefoxPack member (in enum declaration order) whose
profiles.ini happens to exist.

Root cause: FirefoxAppDetails.__init__ falls back to
get_valid_packs()[0] when the persisted data-path doesn't resolve to
a known pack. Page.init_gui then passes that single pack into the
profile dropdown as a hard filter, so every other installed browser's
profiles are silently hidden , even though discovery had already found
them. On a machine with Firefox Snap and Waterfox installed, this
means the Waterfox profiles exist, are detected, and never appear in
the UI.

Fix

• src/page.py: stop filtering the profile list by pack while
  "Automatic Discover" is selected , pass None as the filter, which
  filter_profiles already treats as "show everything".
• src/gui/pack_selector.py: clear PackSelector.package back to
  None when the user switches back to Auto, instead of leaving it at
  whatever specific browser was last chosen (previously this left a
  stale filter in place even after re-enabling autofind).
• src/profile.py: display_name now includes the owning pack name,
  since with every browser listed at once, profile names can collide
  across browsers (e.g. two default-release profiles from different
  installs).
• data/dev.qwery.AddWater.metainfo.xml.in: mentions Waterfox and
  CachyOS Browser in the feature list, matching the existing
  FirefoxPack entries and the "Waterfox support." release note that
  was already present but undocumented in the description.

I initially also tried to keep the backend's tracked data-path in
sync with whichever profile was actively selected while autofinding
(for accurate status reporting). Real-device testing caught that this
caused a repeat-install loop , the theme got reinstalled into multiple
profiles within seconds of a single launch, confirmed via traceback
instrumentation and absent on the unmodified code. That code has been
removed; it wasn't needed for the fix since installation always
operates on the selected Profile's own path, never on the tracked
package.

Testing

Verified on a machine with Firefox Snap, native Waterfox, and Waterfox
Flatpak all installed:

• Before: profile dropdown showed only Firefox Snap's profile while on
  Automatic Discover.
• After: dropdown lists all 5 real profiles across all three browsers,
  correctly disambiguated by pack name.
• Ran the exact install code path (Backend.begin_install) against a
  real native Waterfox profile , confirmed chrome/firefox-gnome-theme/,
  userChrome.css's @import, and
  legacyUserProfileCustomizations.stylesheets all landed correctly,
  and no other profile was touched.
• Confirmed zero spurious reinstalls across repeated clean launches
  after removing the sync code above.
• Selecting a single specific browser manually still correctly narrows
  the profile list to that browser only (no regression to existing
  behavior).

[largestgithubuseronearth]

1) This is the wrong solution to this problem. The right solution is to have one combobox that just sorts profiles by their package. Like so

WIP Screenshot

But that requires extra design work and refactors. Not a quick hack.

2) I'm not interested in reviewing LLM generated code. Sorry. There are too many problems with the submission as is: main change is smeared across two commits for no reason; metainfo change should be its own commit; Messages are way too verbose. I could provide feedback but at that point I'm just playing telephone with Claude through you.