wolf: document the ES-DE/RetroArch-in-Steam workflow in the generated README

The steam-setup-frontends command and the ES-DE/RetroArch AppImage
download step had no matching section in the ~/docker/wolf/README.md
content this file generates, unlike every other manage.sh command. Adds
one, alongside the existing Cemu-in-Steam section: why you'd want it,
how the mounts/cores are already shared, and the two honest caveats
(returning to Steam from ES-DE only works via this path, and whether
controller mappings sync across separately-paired Wolf clients is
expected but unconfirmed).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015Z4nqULUEipWNgBsPoSuAb

services/wolf.sh

@@ -5176,6 +5176,69 @@ container-created virtual controllers specifically (real hardware behaves
 this way; whether Steam Input sees Wolf's virtual joypads the same way is
 still to be tested) — worth trying before assuming it works.
 
+## Running ES-DE and/or RetroArch through Steam instead of their own Wolf apps
+The same Steam Input reasoning above applies beyond just Cemu: ES-DE and
+RetroArch both ship their own official standalone Linux AppImages
+(separate from the \`esde\`/\`retroarch\` Wolf catalog apps this installer
+already runs), and adding one of those to Steam gets you the same
+per-device controller assignment for every system it covers, not just
+Cemu. \`sudo ./setup.sh wolf\` offers to download both (opt-in, default
+no) right after the Cemu step — ES-DE's from its GitLab releases (it
+isn't on GitHub), RetroArch's from \`hizzlekizzle/RetroArch-AppImage\` (a
+well-regarded third-party nightly build — libretro.org's own buildbot
+doesn't publish through an API this installer can automate against).
+Both land in \`emulators/\` under a fixed name (\`ES-DE.AppImage\` /
+\`RetroArch.AppImage\`) regardless of the real release asset's own
+filename, so Steam's non-Steam-game matching finds them reliably.
+
+They reuse the exact same \`roms/\`, \`saves/\`, \`bios/\`, \`retro-home\`, and
+\`retroarch\` (cores/shaders/overlays) directories the \`esde\`/\`retroarch\`
+containers already use — the \`steam\` Wolf app mounts all of the same
+paths, so nothing needs re-downloading or re-scraping just because it's
+now also reachable from Steam. If you haven't already populated cores:
+\`\`\`bash
+cd $WOLF_DIR && ./manage.sh cores all
+\`\`\`
+
+Finishing the Steam side needs one thing that can't be scripted — Steam
+Guard's QR-code sign-in requires a phone approving a prompt — so this
+polls for it instead of trying to script past it:
+\`\`\`bash
+cd $WOLF_DIR && ./manage.sh steam-setup-frontends
+\`\`\`
+Starts Wolf if it isn't already up, checks whether Steam's already
+signed in (proceeds immediately if so), otherwise prints the QR-code
+steps and waits (up to 10 minutes) for sign-in to complete, then adds
+whichever of ES-DE.AppImage/RetroArch.AppImage was downloaded as a Steam
+non-Steam game — re-using \`steam-add-nonsteam-game\` above rather than
+duplicating its shortcuts.vdf-writing logic. Safe to re-run any time
+(e.g. if it timed out waiting, or you downloaded the second AppImage
+later) — already-added shortcuts are updated in place, not duplicated.
+
+**Returning to Steam from ES-DE, without a second instance:** if ES-DE
+is running as a Steam non-Steam game (via the AppImage above, not the
+separate \`esde\` Wolf app), Steam is the parent process the whole
+time — quitting ES-DE drops you back into the same still-running Steam
+Big Picture session rather than starting a new one. This only works for
+the AppImage-in-Steam path; the standalone \`esde\` Wolf app is a
+completely separate container, and Wolf has no supported way to hand off
+from one running app to another mid-session (switching apps means
+closing the Moonlight session and reconnecting to the other one).
+
+**Multiple devices, same Steam account, same controller mappings?**
+Worth knowing before relying on it: Wolf gives each *paired client* its
+own separate Steam container/home directory (confirmed against this
+repo's own \`_steam_home()\` — it searches across multiple
+\`.../Steam\` directories, not just one), so a second device connecting
+to Wolf doesn't reuse the first device's Steam install and has to sign
+in separately the first time. Once it's signed into the *same* Steam
+account, Valve's own account-level Steam Cloud config sync should
+replicate your Steam Input controller bindings across those separate
+local installs (the same mechanism that syncs bindings between a Steam
+Deck and a gaming PC) — but that's a Steam-account feature, not
+something Wolf or this installer controls, and hasn't been confirmed
+live in this specific setup.
+
 ## Multiple controllers (same game/emulator can't tell them apart)
 **Symptom:** two or more controllers connected through the same Moonlight
 session, but the game/emulator only ever sees one — the first controller