feat(fleet): give the media servers an I/O share that actually exists

A Plex section scan walked 50k files at ~850 r/s and nothing bounded it.
`IOWeight=` in a quadlet looks like the fix and does nothing: systemd delegates
`cpu memory pids` to user@.service and NOT io, and it drops a resource line it
cannot honour without a word — the container boots healthy and its cgroup has no
io.weight file at all. Same family as RequiresMountsFor= (inert in the user
manager) and ConditionPathIsMountPoint= (fail-dead).

Place the two system drop-ins that make the controller reachable (user.slice
IOAccounting=yes puts io in user.slice/cgroup.subtree_control, measured
immediately; user@1000.service DelegateControllers gains io and lands at the
next reboot, because restarting the user manager would kill every rootless
container on the host), then ask for the share: IOWeight=10 on jellyfin and plex.
10 is a convention, not a measured optimum — proportional share, only bites
under contention, only requirement is far below the default 100.

ensure_user_io_delegate places both from git and prints NOTE: io is not
delegated … inert until the next reboot, so the quadlet line never reads as live
config. Verified on the host: subtree_control flipped to `cpu io memory pids`,
the drop-in is attached and parsed (systemctl cat), and the podman 5.7 generator
emits IOWeight=10 for both units (bare key; UnitConfigItem= not needed).

Two limits recorded instead of hidden: a container's weight covers its whole
cgroup (scan and playback share it), and the comparison happens inside
user.slice, so it cannot push a rootless unit below a root unit such as
frank-archon — that pairing is user.slice's own weight, a separate call.

Docs: Quadlet Lifecycle 4b (the three-command read of the chain), Pi-hole (all
rootless containers share one 10.0.2.100, so one chatty container throttles DNS
for the host — 8 events today), E2E Suite gotcha 7 (the gate depends on the
runner's resolver: 21 reds on a lost wired link, 37/37 minutes later).

Seam: an in-repo IOWeight= may only exist when both drop-ins exist AND the
deployer places them. ./tests/run.sh: 789 ok, exit 0.

serverAppConfigs-docs/Architecture/E2E Suite.md

@@ -100,3 +100,12 @@ aborts with `DEPLOY INCOMPLETE: e2e gate FAILED` when it does not pass
    hand-off list (`HANDOFFS`) instead of a single host. The guard contract is
    untouched: challenge cleared, no authentik `uidField`, status < 500, and every
    host NOT in the list still has to land on its own vhost.
+7. **The runner's resolver is part of the suite.** A 2026-10-31 deploy of one
+   Dankserver quadlet failed the gate with 21 reds spread over SSO, homepage RBAC
+   and every vhost crawl — precisely the specs that navigate to an absolute
+   `*.franksdank.cloud` name, while every spec on the relative `baseURL` stayed
+   green. The error was `net::ERR_NAME_NOT_RESOLVED`: the workstation had lost its
+   wired link, and on the fallback its resolver was no longer pinned to Pi-hole.
+   Nothing on the fleet was wrong — the same suite re-run minutes later passed
+   37/37. Before a mass red gets blamed on the guard chain, run
+   `resolvectl query grafana.franksdank.cloud` on the box that runs the gate.