docs: remove bind-propagation=shared, document runc v1.3.5 crash

runc v1.3.5 (Docker 29.x / Unraid 7.3+) crashes on bind-propagation=shared
with any container — not GPU-specific. Ramdisk tmpfs is already MS_SHARED
at kernel level; propagation is automatic and the option is unnecessary.

- Remove bind-propagation=shared from all example Extra Parameters
- Update "Why shared Is Required" → "Mount Propagation — Unraid 7.3+"
- Update GPU troubleshooting section to cover the general runc crash
- Verify commands updated (no longer checking for Propagation: shared)
- Historical notes preserved explaining why it existed before

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Transcodes/README-Transcoding.md

@@ -6,16 +6,15 @@ without interrupting anything already playing. When pressure drops, new sessions
 back to RAM.
 
 > **Three configuration requirements that are not obvious and were all discovered the
-> hard way in production.** The Docker mount must use `bind-propagation=shared` or
-> symlink flips are silently ignored after the first flip. The `transcoding-temp`
-> directory must be pre-created on the ramdisk or Emby finds the SSD version and
-> routes all sessions there until restarted. GPU containers require `--gpus "device=UUID"`
-> in Extra Parameters — not `--runtime=nvidia` — or the container fails to start after
-> unRAID 7.2.5. Additionally: any GPU-accelerated sidecar (OCR plugins, credit detection)
-> that holds VRAM and never releases it will starve Emby and Jellyfin of VRAM for
-> transcoding — Jellyfin hard-fails, Emby silently falls back to CPU. Emby's startup
-> NVIDIA probe is one-shot: if VRAM is exhausted when the container starts, NVIDIA stays
-> disabled for the entire session. All three are documented in Manual-Transcoding.md.
+> hard way in production.** The `transcoding-temp` directory must be pre-created on
+> the ramdisk or Emby finds the SSD version and routes all sessions there until
+> restarted. GPU containers require `--gpus "device=UUID"` in Extra Parameters —
+> not `--runtime=nvidia`. Do **not** use `bind-propagation=shared` on Unraid 7.3+
+> (Docker 29.x / runc v1.3.5+) — it crashes container start; the ramdisk is already
+> MS\_SHARED at the kernel level. Additionally: any GPU-accelerated sidecar (OCR plugins,
+> credit detection) that holds VRAM and never releases it will starve Emby and Jellyfin
+> of VRAM for transcoding — Jellyfin hard-fails, Emby silently falls back to CPU.
+> All three are documented in Manual-Transcoding.md.
 
 ---
 
@@ -24,21 +23,20 @@ back to RAM.
 > **Stop. Set this before starting Emby or Jellyfin. If you Google how to add GPU
 > access to a Docker container on unRAID you will find the wrong answer.** Every
 > forum post and guide shows `--runtime=nvidia` + `NVIDIA_VISIBLE_DEVICES`. That
-> method conflicts with `bind-propagation=shared` on unRAID 7.2.5+ and breaks on
-> container rebuilds. Use `--gpus` instead.
+> method breaks on container rebuilds. Use `--gpus` instead.
 
 In the unRAID Docker template, open **Advanced View** and paste the following into
 the **Extra Parameters** field. Do not use the path mapping UI for the transcode
-directory — it does not support `bind-propagation`.
+directory — it does not support the `--mount` syntax.
 
 **GPU-accelerated (Emby, Jellyfin with NVENC/NVDEC) — use this:**
 ```
---gpus "device=GPU-62e1659d-1ed4-935f-3df3-4bb4339438f1" --pids-limit=0 --mount type=bind,source=/mnt/ram-transcode,target=/ext-ram-transcode,bind-propagation=shared
+--gpus "device=GPU-62e1659d-1ed4-935f-3df3-4bb4339438f1" --pids-limit=0 --mount type=bind,source=/mnt/ram-transcode,target=/ext-ram-transcode
 ```
 
 **Non-GPU — use this:**
 ```
---mount type=bind,source=/mnt/ram-transcode,target=/ext-ram-transcode,bind-propagation=shared
+--mount type=bind,source=/mnt/ram-transcode,target=/ext-ram-transcode
 ```
 
 In Emby and Jellyfin's transcoding settings, set the transcode temp path to `/ext-ram-transcode`.
@@ -66,14 +64,13 @@ Fix: symlink indirection. Emby points at a fixed path. The symlink target change
 ffmpeg resolves the symlink once at session start — existing sessions are completely
 unaffected by flips. Only new sessions follow the new target.
 
-**Docker Bind Mount Silently Ignored After First Flip**  
+**Docker Bind Mount Silently Ignored After First Flip** *(historical — resolved differently)*  
 Symlink flip from ramdisk → SSD worked. Flip back: nothing. All new sessions still land
 on SSD. The symlink on the host is correct. Emby doesn't see it.  
-Cause: Docker's default `rprivate` propagation resolves the symlink target at mount time
-and locks that inode. Subsequent flips are invisible to the container.  
-Fix: `bind-propagation=shared` in Extra Parameters. Host mount changes propagate into
-the container in real time. Requires `--mount` syntax — the path mapping UI doesn't
-support propagation.
+Original fix was `bind-propagation=shared` — but this crashes runc v1.3.5+ (Docker 29.x,
+Unraid 7.3+) on any container start. The ramdisk tmpfs is `MS_SHARED` at the kernel level,
+so propagation is inherited automatically without specifying it in Docker. Do not add
+`bind-propagation=shared` to Extra Parameters.
 
 **Sessions Drifting to SSD After a Day of Operation**  
 System working correctly for hours, then sessions gradually drift to SSD despite the