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

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.