Replaces the server/pages/community.vue stub ({{ $t("todo") }}) with real
Nuxt pages: a unified Drop+RomM title browser, an admin catalog-sync panel,
and a profile page with playtime rails. Corrects the original architecture
mistake of building this as a separate service at community.quasarke.net --
now that we own the fork's source, community is ordinary Nuxt pages instead
of a sidecar with its own auth/DB/vhost.
Data model: one new table, CommunityTitle, for the RomM catalog (ported
from drop-community M1's Title spine). Drop's own Game/User/Playtime models
already ARE the title/identity/playtime spine for Drop content, so nothing
new was needed there -- profile playtime rails read real, already-existing
Playtime rows, no wrapper/ingest milestone required to populate them.
RommAdapter (server/server/internal/community/rommAdapter.ts) reads RomM's
MariaDB directly via the community_ro read-only role, same deviation and
same reasoning as M1's adapter (RomM's /api/roms needs a browser session,
no service-account key). TitleSyncService runs every 6h
(scheduledTasks.communityTitleSync) and via an admin "Sync now" button
(system:community:sync ACL) -- never deletes, hides instead.
Also folds the three post-build JS patches
(homelab-compose/drop-stack/patch-{launcher-button,telemetry-snippet,
footer-links}.js) into source now that the fork builds from source instead
of patching upstream's prebuilt image:
- library/game/[id]/index.vue: the "Open in Launcher" button gets a real
@click handler (drop://open with a timeout fallback to /download).
- plugins/telemetry.client.ts: OpenPanel RUM injected via a Nuxt client
plugin instead of appending to the compiled entry chunk.
- UserFooter.vue + admin/library source-help links + error.vue + the
Weblate link: repointed at our own infra. The Discord/social link
used to point at community.quasarke.net; that service is retired, so
it now points at /community directly.
I never used headlessui before, so I have no idea why this is needed, but it looks like this fixes the problem. I think a high z-index is alright, because there shouldn't be things that should lie above the options.
