Close the desktop store item, and fix a check that had started lying

MORE_STORES item 2 is done: stores/warp-engine-desktop-store and
stores/ttg-desktop-store. The write-up records what the implementation changed
about the plan — chiefly that the `html` asset is not a downloadable archive but a
hosted directory, so a browser title becomes a menu entry that opens its page
rather than an offline install.

Separately: `check-repos.sh` reported `infra/wiki-pages` as STALE while the repo
was plainly there. Gitea caps a page at 50 items whatever `--limit` says, so
`tea repo list --limit 1000` had been quietly returning the first 50 — invisible
until today, when the estate reached 51 repos. The check now pages through, and
fails loudly if the server returns nothing at all rather than declaring the whole
workspace stale.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

MORE_STORES.md

@@ -2,6 +2,13 @@
 
 Készült 2026-08-16-án, a `warp-engine-batocera-store` szétválasztása után. A kérdés: a batocera-store mintájára milyen más gazdaplatformra tudnánk store-t adni.
 
+> **2026-08-18: újramérés a doksi végén.** Két store és a kiemelt közös mag után
+> a kérdés újra feltéve — új jelöltekkel (Pegasus, Lutris), egy korrekcióval
+> (az ES-DE nem drop-in, a Steam alá van becsülve), és egy méréssel, ami az
+> egész listát átrendezi: a katalógus 8/15-e `demo` vagy `development`, tehát a
+> store-ok ma 7 címet látnak. Az alábbi lefedettségi számok a demókat is
+> beszámolják.
+
 ## A mérés, ami átrendezi a kérdést
 
 A katalógus legfrissebb kiadásaiban (15 szoftver) ennyi asset van (2026-08-17-i mérés):
@@ -79,6 +86,8 @@ Ugyanez a keret adja az interaktív ES-menüt is (ports bejegyzések gamelist-me
 ## Új store-ok, sorrendben
 
 ### 1. ES-családú store-ok
+*(A 2026-08-18-i szakasz ezt pontosítja: az ES-DE nem drop-in — máshonnan olvassa a gamelisteket, mint ahová a Batocera-adapter ír.)*
+
 RetroPie, Recalbox, ES-DE, és a kézikonzolos disztrók (muOS, ArkOS, JELOS). Ugyanaz a `gamelist.xml` + ROM-mappa modell, amire a motor **már generikus**: gyakorlatilag `paths.roms_root`, rendszernév-leképezés és egy másik telepítő kell. A legtöbb elérés a legkevesebb munkáért. Az ES-DE Windowson és macOS-en is fut, tehát asztali elérést is ad mellékesen.
 
 Fontos megkötés: a **kézikonzolok jóformán mind ARM-osak**, és a RetroPie is Pi-n fut. Cartridge-dzsel ezek azonnal kiszolgálhatók, natív játékkal viszont csak a 0. pont ARM buildjei után.
@@ -86,6 +95,14 @@ Fontos megkötés: a **kézikonzolok jóformán mind ARM-osak**, és a RetroPie
 ### 2. Asztali store — `warp-engine-desktop-store`
 A per-OS zipeket telepíti egy helyi könyvtárba, és indítót csinál hozzá (`.desktop`, Start menü bejegyzés, `.app`). Ma 8 szoftvert szolgálna ki, és a CI-lefedettséggel nő. Ez a legnagyobb valóban új képesség: asztali gépre ma **semmilyen** utunk nincs.
 
+**Kész (2026-08-18).** `stores/warp-engine-desktop-store` + `stores/ttg-desktop-store`.
+Két telepítési mód: `app` (a per-OS zip kicsomagolva, menü-bejegyzéssel) és `web`
+(a kiszolgált böngészős build oldalát megnyitó bejegyzés) — utóbbi azért, mert a
+`html` asset **nem letölthető archívum**, hanem egy kiszolgált könyvtár. A kettő
+visszaesési sorrendben van, ezért egy natív build nélküli cím is bekerül a menübe:
+gépenként **10 cím** (a demókkal). macOS-en végigmérve és a játékok valóban
+elindítva; Linux és Windows valódi gépen még nincs kipróbálva.
+
 ### 3. Steam-könyvtár
 A `shortcuts.vdf`-be írva a játékaink megjelennek a Steam könyvtárban borítóval — és ezzel a Steam Decken is. A letöltést a 2. pontról örökli, tehát ráépül, nem mellé megy. Bevált technika, a Heroic és a Lutris is ezt teszi.
 
@@ -106,6 +123,8 @@ A `bbs/bbs-server`-be, a saját `rubbs`-unkra épülve. Bármelyik asset-fajtát
 Homebrew tap és Scoop bucket: `brew install ttg/tap/rabbitroller`. Kevés munka, és nem kell hozzá launchert írni; a 2. pont csomagolására épül.
 
 ### 7. Webes könyvtár / PWA
+*(2026-08-18: **levéve** — a `html`-t az asztali store, a Pegasus és az ES-DE viszi el egy indítóval; lásd a doksi végét.)*
+
 A `html` assetek megvannak, de ez van a legnagyobb átfedésben a mostani publikus oldallal, ezért a legkisebb határhasznú — annak ellenére, hogy ez a legelterjedtebb assetünk.
 
 ---
@@ -137,3 +156,181 @@ Egy dolog viszont **nem** tartozik az adapterbe, hanem a közös részbe: az **a
 ## Amit valódi gépen kell ellenőrizni
 
 A 2. és 3. pont azon áll vagy bukik, hogy a per-OS zipjeink **önmagukban futtathatók-e**: van-e hiányzó függőség Linuxon, és mit szól hozzá a macOS aláírás-ellenőrzése egy nem jegyzett binárishoz. Erről a katalógus nem árulkodik, csak egy próba.
+
+---
+
+# Újramérés és új jelöltek — 2026-08-18
+
+*Két store és a kiemelt közös mag után újra feltéve a kérdés. A formátum-állítások
+alább vagy a gépen mérve, vagy a hivatkozott dokumentációból ellenőrizve vannak; ahol
+nem sikerült ellenőrizni, az külön ki van írva.*
+
+## A mérés, ami megint átrendezi a kérdést: a `status`
+
+A doksi eddigi lefedettségi számai (13/15, 9/15) **a demókat is beszámolják**. A
+store-ok viszont alapból nem: mindkettő configjában `catalog.statuses:
+["released", "archived"]`. A mai katalógus 15 bejegyzése így oszlik:
+
+| `status` | Darab | Store-ban látszik ma |
+|---|---|---|
+| `released` + `archived` | **7** | ✔ |
+| `demo` | 6 | ✘ |
+| `development` | 2 | ✘ |
+
+Ugyanaz a lefedettség a kétféle szűréssel:
+
+| Amit a gazdaplatform enni tud | Minden status | Csak `released`+`archived` |
+|---|---|---|
+| `cartridge` | 7 | **6** |
+| `html` | 11 | **4** |
+| bármilyen natív (win/linux/mac) | 9 | **4** |
+| `cartridge` + natív | 13 | 6 |
+| mindent, `html`-lel együtt | 15 | 7 |
+
+**A tanulság:** a szűk keresztmetszet ma nem a store-ok száma és nem is az
+asset-fajta, hanem az, hogy a katalógus 8/15-e `demo` vagy `development`. Egy
+harmadik store nulla új *tartalmat* ad — csak új *gépeket*.
+
+És hogy a `demo` státusz melyik store-t érinti, az nem érzésre kitalálható, ezért
+kimérve (`catalog.statuses` bővítése mit ad):
+
+| Store-fajta | ma | `+ "demo"` | `+ "development"` |
+|---|---|---|---|
+| cartridge (Batocera ROM-út, RetroArch) | 6 | **6** (+0) | 7 (+`c64-demo`) |
+| asztali, natív | 4 | **9** (+5) | 9 (+0) |
+| asztali, natív **vagy** `html` | 4 | **10** (+6) | 11 (+`trickster-tiles`) |
+
+**A meglévő két store-on tehát a demók engedélyezése semmit nem változtat**:
+egyetlen cartridge-címünk sem `demo`. A 7. cartridge-cím a `c64-demo`, ami
+`development` — vagyis befejezetlen, azt épp nem akarjuk kiadni.
+
+A `demo` kérdés ezért nem a mai store-ok kapcsolója, hanem **az asztali store
+előfeltétele**: demók nélkül az asztali store 4 címmel indulna, velük 10-tel. Ez
+dönti el, hogy megéri-e megírni. A `REPO_REFACT.md` szerint a `demo` státusz épp
+azt jelenti, hogy „nem önálló termék" — tehát terméki döntés, nem technikai.
+
+## Az `html` kérdése: nem webes könyvtár kell hozzá, hanem indító
+
+A `html` a legelterjedtebb assetünk (11/15), és továbbra sincs fogyasztója. A 7.
+pont ezt „webes könyvtár / PWA"-ként vette fel, és ezért lett a legkisebb
+határhasznú. A mérések szerint viszont máshol van a válasz.
+
+**Batocerán nincs.** Ellenőrizve: a BUA böngésző-bejegyzései Flatpak/AppImage
+alapúak, a Batocera Flatpak-támogatása pedig dokumentáltan x86_64-only — ARM-on,
+tehát Pi-n és a kézikonzolokon, nincs böngésző. A `html` a Batocera-store számára
+zsákutca; ezt a `ttg-batocera-store` README-jében is érdemes kimondani, hogy más
+ne próbálja.
+
+**Asztali gépen viszont majdnem ingyen van**, mert ott van böngésző. Amelyik
+gazdaplatform **bármilyen parancsot** el tud indítani, az a `html`-t is tudja:
+
+| Gazdaplatform | Mivel indítja a `html`-t | Ellenőrizve |
+|---|---|---|
+| Lutris | `web` runner (`lutris/runners/web.py` létezik) | ✔ a forrásfában |
+| Pegasus | per-game `launch`/`command` felülírás, tetszőleges parancs | ✔ a dokumentációban |
+| ES-DE | `~/ES-DE/custom_systems/es_systems.xml`, saját parancs | ✔ a USERGUIDE-ban |
+| asztali store (2. pont) | `.desktop` / `.lnk` / `.app`, ami `xdg-open`-t hív | — |
+
+Vagyis a `html` a **2. pont asztali store-jába** tartozik egy második
+telepítési módként (ahogy Batocerán a `port` lett a `rom` mellé), nem egy külön
+webes store-ba. Ez a 7. pontot gyakorlatilag leveszi a listáról.
+
+## Új jelöltek, amik eddig nem voltak a listán
+
+### Pegasus Frontend — a legjobb új jelölt
+Sima szöveges `metadata.txt`: `collection` + `game` blokkok, per-game
+`launch`/`command` felülírás, `{file.path}` behelyettesítéssel, `developer`,
+`release`, `rating` mezők. **Windows, macOS, Linux, Raspberry Pi és Android** —
+egy adapter, ami mind a három asset-fajtánkat viszi: cartridge (emulátort indít),
+natív (közvetlenül), `html` (böngészőt). A formátum egyszerűbb, mint a
+`gamelist.xml`, és nincs benne olyan csapda, mint a RetroArch bináris/PNG-kényszere.
+
+### ES-DE — de nem drop-in, ahogy az 1. pont sejteti
+Az 1. pont az ES-családot egy tételként kezeli, „a motor már generikus" felkiáltással.
+A USERGUIDE ezt két ponton megcáfolja:
+
+- A gamelisteket **nem** a ROM-mappából olvassa, hanem a központi
+  `~/ES-DE/gamelists/` fából — a ROM-fában lévőket alapból **figyelmen kívül hagyja**.
+  A mi Batocera-adapterünk pontosan oda ír, ahonnan az ES-DE nem olvas.
+- A `path` tagben **kötelező a `./` prefix** (a mi merge-ünk szerencsére már így írja).
+
+Cserébe többet ad, mint a Batocera: fut Linuxon, macOS-en, Windowson, **Androidon**,
+Haikun és Steam Decken, és `custom_systems/es_systems.xml`-ben saját rendszert lehet
+definiálni tetszőleges indító paranccsal — tehát nála is megvan a `html`-út.
+Az adapter tehát nem a Batocera-adapter újrahasznosítása, hanem egy testvére:
+ugyanaz a metaadat-formátum, más útmodell.
+
+### Lutris — egy Linux-asztali gépen elvileg 15/15
+Ellenőrizve: a Lutris-installer lehet **tisztán lokális YAML**, weboldal nélkül
+(`lutris -i /path/to/file.yaml`), a kulcsok a gyökérben, minden más a `script`
+alatt, `$SCRIPTDIR`-rel relatív fájlokra. A runnerek között ott van a `linux`
+(natív), a `web` (böngésző) és a `wine` — vagyis egy Lutris-store a `html`-t, a
+Linux-natívot és akár a Windows-buildeket is fel tudja tenni **ugyanabba a
+könyvtárba**. Ez a legnagyobb elméleti lefedettség a listán.
+
+A minta viszont más: nem mi írjuk a könyvtárformátumot, hanem generálunk egy
+telepítőt és meghívjuk a Lutrist. Kevesebb kontroll (a prune-hoz a Lutris saját
+adatbázisát kellene bántani), de a `state.json`-unk így is tudja, mit tettünk fel.
+
+### LaunchBox és Playnite — nem tudtam ellenőrizni
+Mindkettő nagy Windows-közönség, és mindkettőnél elakadtam:
+
+- **LaunchBox**: a játéklista `Data/Platforms/<Platform>.xml`-ben van, de a séma
+  nincs dokumentálva (a közösség visszafejtette), és az alkalmazás maga is
+  újraírja a fájlt. Egy valódi telepítés nélkül nem érdemes tervezni rá.
+- **Playnite**: a hivatalos út egy C#/.NET library plugin, nem egy adatfájl —
+  ez kilóg a „stdlib Python + egy fájl" mintánkból. A dokumentációt nem sikerült
+  elérnem (403), tehát ez is nyitott kérdés.
+
+Egyik sem javasolt a Pegasus és az ES-DE előtt.
+
+## Korrekció a meglévő listához: a Steam alá van becsülve
+
+A 3. pont szerint „a letöltést a 2. pontról örökli, tehát ráépül" — a letöltést
+igen, a formátum viszont a listán a legkellemetlenebb:
+
+- A `shortcuts.vdf` **bináris VDF**, nem szöveg: `appid` (4 bájt little-endian),
+  `AppName`, `Exe`, `StartDir`, `LaunchOptions`.
+- Az `appid` az exe és a név CRC32-jéből számolt érték, a legfelső bit beállítva —
+  és ez az `appid` a borítóképek fájlneve is (`userdata/<id>/config/grid/<appid>p.png`).
+- **Ha a fájl hibás, a Steam indulás után törli**; ha a felhasználó a Steam UI-ból
+  vesz fel egy nem-Steam játékot, felülírja, amit írtunk. Írás után Steam-újraindítás
+  kell.
+- A `userdata/<id>` ág felhasználónként más, tehát felderítés is kell hozzá.
+
+Bináris formátumot írni stdlib Pythonból megoldható, de ez nem „kevés munka", és
+egy elrontott fájl a felhasználó teljes nem-Steam listáját viszi. A 3. pont ezért
+a 2. pont **után** és önálló körben való, nem mellékesként.
+
+## Az újrarendezett sorrend
+
+1. **Döntés a demókról** — 0 kód, de nem a mai store-okról szól: azokon nem
+   változtat semmit (nincs `demo` státuszú cartridge-ünk). Az asztali store
+   értelmét dönti el: 4 cím demók nélkül, 10 velük. Ezért ez a 2. pont
+   előfeltétele, nem önálló nyereség.
+2. **Asztali store** (2. pont) — változatlanul a legnagyobb valóban új képesség,
+   most már azzal, hogy a `html` is bele tartozik egy második telepítési módként.
+   Ez teszi elérhetővé a katalógus 15/15-ét (a demókkal együtt).
+3. **Pegasus** — egy adapter, ami mind a három asset-fajtát viszi öt platformra,
+   köztük Androidra, szöveges formátumban. A legjobb arány a listán.
+4. **ES-DE** — ugyanaz a metaadat-formátum, más útmodell; desktop + Android +
+   Steam Deck. Az 1. pont maradéka (RetroPie, Recalbox, kézikonzolok) ezután jön,
+   mert azok a Batocera-adapterhez állnak közelebb.
+5. **Steam** (3.) — a 2. pontra épül, de önálló körben, a bináris formátum miatt.
+6. **BBS store** (5.) — változatlanul a márkaérték-tétel, nem elérés-tétel.
+7. **Csomagkezelők** (6.) — a 2. pont csomagolására épül.
+8. ~~**Webes könyvtár / PWA**~~ (7.) — **levehető**: a `html`-t a 2., 3. és 4. pont
+   viszi el, ez pedig a publikus oldallal fedne át.
+
+## Amit valódi gépen kell ellenőrizni (bővítve)
+
+A korábbi kettő (per-OS zipek önmagukban futtathatók-e; macOS-aláírás) mellé:
+
+- **Pegasus**: elolvassa-e a generált `metadata.txt`-t Androidon is, és mit tesz a
+  `launch` paranccsal ott (Android-on nincs shell úgy, ahogy asztalon).
+- **ES-DE**: a `~/ES-DE/gamelists/` fába írt metaadat és a `custom_systems` együtt
+  működik-e, illetve mit lát az ES-DE Android-kiadása.
+- **Lutris**: a `lutris -i` fut-e fejetlenül (headless), vagy GUI-t nyit — ez dönti
+  el, hogy egy szinkron automatizálható-e.
+- **LaunchBox / Playnite**: van-e egyáltalán írható formátum. Egy telepítés
+  megválaszolja; addig ne tervezzünk rájuk.