feat(frank-dragoon): open the NPU node the way rootless can actually reach it

The armed boot reached the engine and died in its own preflight:

  halogen npu: /dev/accel/accel0 is here, but this process cannot open it
    (crw-rw---- nobody:nogroup).

The node is root:render 0660 and a rootless container maps exactly one uid/gid,
so `render` is unmapped inside it and `--group-add keep-groups` — the vendor's
advice, and the ComfyUI pattern for /dev/kfd — cannot grant a group the
namespace does not map. Measured 2026-10-19 from a `dank` shell already in
`render`: without the flag denied, with the flag denied, with the udev mode
0666 the open succeeds (OPEN_OK). Same wall 99-comfyui-gpu-access.rules already
solved for the GPU compute nodes, so the accel node gets its counterpart:

  dankclaw/udev/98-halogen-npu-access.rules — KERNEL=="accel[0-9]*",
  SUBSYSTEM=="accel", MODE="0666"

The deployer installs the rule, reloads rules, re-triggers the node and only
then checks the mode; the serve script refuses any node that is not
other-writable, naming the rule, so this cannot return as a crash loop (189
restarts while chat was down is the failure mode being closed).

Both checks read the permission bit directly: `[ -o FILE ]` is not
"other-writable" — it means "exists" and `-o` doubles as the OR operator inside
test, which is why the first cut of the gate refused everything.

Dragoon seam: 33 -> 35 tests. The fixture node is 0666 like the installed one,
a 0660 node is refused with the rule named and nothing rendered, and the rule
file's shape plus the deployer's install/trigger are asserted.

serverAppConfigs-docs/LLM/frank-dragoon.md

@@ -240,8 +240,15 @@ precondition that surfaces as an engine crash-loop is a gate that was never writ
 box as of 2026-10-19; the endpoint still runs with the lane **off** until that day's mount fix merges, and the first
 armed boot's evidence lands here with it:
 
-1. `--device /dev/accel/accel0` plus `--group-add keep-groups` (the pattern ComfyUI uses for `/dev/kfd`; `dank` is
-   already in `render`).
+1. `--device /dev/accel/accel0` **and** a node the container's namespace can open. `/dev/accel/accel0` is
+   `root:render 0660` and a rootless namespace maps exactly one uid/gid, so the engine's own first words are
+   *"this process cannot open it (crw-rw---- nobody:nogroup)"*. `--group-add keep-groups` — the vendor's advice and
+   the ComfyUI pattern for `/dev/kfd` — is **dead in this shape**: measured 2026-10-19 from a `dank` shell already
+   in `render`, with and without the flag the node stayed `nobody:nogroup` and the open was refused; an unmapped
+   gid cannot be granted across a namespace that does not map it. The door is the udev mode
+   (`dankclaw/udev/98-halogen-npu-access.rules`, installed and re-triggered by the deployer, `0666` like the GPU
+   compute nodes beside it); the serve script refuses any node that is not other-accessible, so the fault cannot
+   return as a crash-loop.
 2. The host's XRT reachable inside: there is **no `/opt/xilinx/xrt`** here — distro packages put the three files the
    container needs (`libxrt_coreutil.so.2`, `libxrt_core.so.2`, `libxrt_driver_xdna.so.2`) in
    `/usr/lib/x86_64-linux-gnu`, where all three exist.