Add manifests for duke and dn3d (Duke Nukem 3D)

Sourced from real played installs at MiscOS\MSDos\games\duke\ and
\dn3d\ on the share (found while comparing that directory against
Games\), not the pre-existing Games\ zips - these only existed as raw
folders, so they were downloaded, re-zipped with the usual <name>/
top-level convention, and re-uploaded alongside their source folders
(zip_path points there, manifests still live in the usual Games\dosbox\
catalog).

Skipped a third variant, duke3d_w32_bin.zip - turned out to be a native
Windows binary, not DOS, per explicit direction not to add Wine for it.

Verified end-to-end with actual screenshots (xwd/xdotool/imagemagick,
installed temporarily in the running container for testing only): both
games genuinely launch and render real gameplay, not just a menu.
Audio doesn't play for either - traced to their carried-over
duke3d.cfg (required; deleting it breaks the game outright) likely
having a stale sound-hardware selection mismatched with DOSBox's
emulated SB16, not a bug in the audio pipeline itself. Documented as a
known gap.

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

CLAUDE.md

@@ -59,7 +59,7 @@ There is **no single shared desktop/display for video** — unlike the other noV
 - `is_running(name)` does the same full teardown **lazily** if the game process exited on its own (quit or crash) — it won't leave an idle Xvnc/websockify pair holding a slot forever just because nobody clicked Stop. `render_page()` calls this for every tracked game on every load, so the slot count and each row's status stay accurate without polling.
 - Each running game's row shows its own "Open Screen" link (only while `Running`) — a plain top-level link straight to that game's own noVNC URL (`https://<host>:<novnc_port>/`, opens in a new tab). Deliberately **not** an iframe — see Audio below for why.
 - Per-game install progress (`install_state`), start errors (`game_errors`), and the running-process table (`running_procs`) are all guarded by one `threading.RLock` (reentrant — several code paths call `is_running()` from inside a block that already holds the lock). The page keeps itself current via `setInterval(refresh, 3000)` (client-side JS, not a server-driven `<meta http-equiv="refresh">` — that would navigate the page and kill the persistent audio connection, see Audio below), so a crashed/exited game's slot shows as freed within a few seconds without ever reloading the page.
-- **Manifests on the share today**: `stuntcar` (DOSBox), `monkey`/`monkey2`/`atlantis`/`indy3`/`tentacle` (ScummVM). `t7g` still has no manifest and won't appear on the setup page until one's added.
+- **Manifests on the share today**: `stuntcar`, `duke`, `dn3d` (DOSBox), `monkey`/`monkey2`/`atlantis`/`indy3`/`tentacle` (ScummVM). `t7g` still has no manifest and won't appear on the setup page until one's added. `duke`/`dn3d`'s zips aren't the pre-existing ones under `Games\` — they're re-zipped copies of real played installs found under `MiscOS\MSDos\games\`, uploaded alongside those source folders (`zip_path` points there, not into `Games\dosbox\`); see `TODO.md` for how that comparison turned them up, and a known audio gap specific to these two (video confirmed working via screenshot, but their carried-over `duke3d.cfg` doesn't seem to have working DOSBox-SB16-compatible sound settings).
 
 **Playing a game — two overlapping paths right now**:
 1. The setup page's Start/Stop buttons (above) — the current way, works for any manifest-driven game, gives it its own screen, and is capped at 10 concurrent.

TODO.md

@@ -171,3 +171,31 @@
   `sampleRate`/`registerProcessor`) that force-feeding a simulated 4.3s burst leaves only
   ~85ms actually queued afterward, instead of growing unbounded. Propagated to both the
   `docker-common` canonical copy and this project's own copy, per the usual convention.
+
+- Added manifests for `duke` (Duke Nukem 3D, unregistered shareware — confirmed via
+  screenshot, "UNREGISTERED SHAREWARE" watermark and the nag screen, despite the folder name)
+  and `dn3d` (Duke Nukem 3D: Atomic Edition), both real DOS Build-engine games, both DOSBox
+  manifests. Sourced from real played installs at `MiscOS\MSDos\games\duke\`/`dn3d\` on the
+  share (found by comparing that directory against `Games\`, which turned up several
+  installs — including these — not present as zips anywhere) rather than the existing
+  `Games\` zips: these are raw, unzipped folders (with real save games, `duke.rts`, etc.), so
+  they were downloaded, re-zipped locally with the usual `<name>/` top-level-folder
+  convention, and re-uploaded as `dn3d.zip`/`duke.zip` alongside the source folders on the
+  share (manifests, as always, still live in the `Games\dosbox\` catalog regardless).
+
+  A third variant found in the same comparison, `Games\duke3d_w32_bin.zip`, turned out to be
+  a **native Windows binary** (`duke3d_w32.exe`, needs `mfc70.dll`/`msvcr70.dll`) rather than
+  a DOS game — DOSBox can't run it; would need Wine, a real new dependency. Skipped per
+  explicit direction rather than expanding scope.
+
+  Verified end-to-end with screenshots (`xwd`/`imagemagick`, installed temporarily for
+  testing only, not part of the image) — both games genuinely launch and render actual
+  gameplay (HUD, level geometry, taking hits), not just a menu. **Audio did not play for
+  either** despite `pactl` showing dosbox as a normal, uncorked sink-input — tracked down to
+  their carried-over `duke3d.cfg` (deleting it entirely breaks the game outright, forcing
+  `SETUP.EXE`, so it's required; likely has a stale/mismatched sound-hardware selection from
+  whatever machine last ran `SETUP.EXE` for real, rather than DOSBox's emulated SB16). Not a
+  bug in the audio pipeline itself — already proven working end-to-end for other games in the
+  sound TODO item above. Left as a known gap for these two specifically; fixing it would mean
+  either reverse-engineering `duke3d.cfg`'s binary format to patch the stored IRQ/DMA, or
+  finding a way to script `SETUP.EXE`'s interactive hardware wizard.