Let applications be chosen a few at a time

The catalog held fourteen applications. This machine runs thirty-four flatpaks,
so most of what is actually used had no way to be installed from here at all --
Zoom, Slack, Obsidian, Spotify, LibreOffice, OBS and its sixteen plugins.

So the catalog is seeded from the machine, and `panama apps` opens it: pick a
category, tick what you want, install just those. ./install still offers the
same catalog as whole categories, because during a first install you want coarse
and fast. Both read setup/lib/extras-catalog. Two parsers would eventually
disagree about what a category contains, and the one that disagreed quietly
would be the one that runs unattended.

Two pieces of syntax earn their keep. A `| Name` suffix gives the menu something
readable, since com.obsproject.Studio is not a name anybody wants to pick from a
list. An indented line belongs to the entry above it, which is how OBS carries
its plugins as one thing to tick rather than seventeen -- they are extensions of
the flatpak, useless alone.

That is also why creative moved from dnf to Flathub: the plugins attach only to
the flatpak, so the dnf build cannot have them. The rest of the category
followed rather than leave one machine with GIMP from dnf and its neighbour from
Flathub.

The contract now reads the catalog through the same parser instead of keeping a
third idea of the format, and checks the two things this syntax can break
silently: a label leaking into an install command, and a bundle that installs
the application without its plugins. It caught a typo in the Pixelorama id on
the first run.

It also got slow enough to be worth fixing -- fifty-one names, each its own
network call. One bulk query per manager took it from minutes to four seconds.
That query needs `flatpak remote-ls --all`: without it, end-of-life applications
are hidden and read as missing, which reported yuzu as gone from Flathub when it
installs perfectly well.

Claude-Session: https://claude.ai/code/session_01Q84axqUE5inJhf5Jz9CFy1

setup/scripts/install-packages

@@ -25,6 +25,11 @@ packages_in() {
 # --- Defined Paths ---
 PANAMA_PATH="$HOME/.local/share/Panama"
 
+# Reading the extras catalog, shared with `panama apps` so the two front doors
+# cannot disagree about what a category contains.
+# shellcheck source=../lib/extras-catalog
+source "$PANAMA_PATH/setup/lib/extras-catalog"
+
 echo -e "\n--- Installing Repositories ---"
 log "Installing RPM Fusion Free and Nonfree Repositories"
 sudo dnf install -y https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm > /dev/null
@@ -197,6 +202,11 @@ fi
 # package and a `flatpak:` line is a Flathub ID, so one file per category holds
 # the whole answer rather than splitting each category across two.
 #
+# Reading the file is setup/lib/extras-catalog's job, not this function's, because
+# `panama apps` offers the same catalog from the other side. Two parsers would
+# eventually disagree about what a category contains, and the one that disagreed
+# quietly would be this one -- it runs unattended.
+#
 # Neither install is fatal. A category is a set of applications somebody wanted,
 # not a dependency of the desktop, and losing the rest of the run because one of
 # them was renamed upstream would be the wrong trade.
@@ -205,8 +215,8 @@ install_extra_category() {
 	name="$(basename "$file")"
 
 	local dnf_packages flatpak_ids
-	dnf_packages=$(packages_in "$file" | tr ' ' '\n' | grep -v '^flatpak:' | tr "\n" " ")
-	flatpak_ids=$(packages_in "$file" | tr ' ' '\n' | sed -n 's/^flatpak://p' | tr "\n" " ")
+	dnf_packages=$(catalog_all_targets "$file" | grep -v '^flatpak:' | tr "\n" " ")
+	flatpak_ids=$(catalog_all_targets "$file" | sed -n 's/^flatpak://p' | tr "\n" " ")
 
 	if [[ -n "${dnf_packages// /}" ]]; then
 		log "Installing $name: $dnf_packages"