fix(pod): systemd-unit mode CHDIRs the host to the container workdir (status=200/CHDIR) #46

Finding

The systemd-unit run mode's emitted unit set WorkingDirectory= to the
CONTAINER's working dir (/home/user), which systemd applies on the HOST
before spawning nerdctl. Every containerd pod start failed
status=200/CHDIR:

charly-check-engine-containerd-pod.service: Changing to the requested working directory failed: No such file or directory
charly-check-engine-containerd-pod.service: Failed at step CHDIR spawning nerdctl: No such file or directory
Main process exited, code=exited, status=200/CHDIR

Measured on the first live pod: / engine: containerd bed for
opencharly/charly#1109. The unit's ExecStart already carries the engine's
run -w <container-path>, so the container workdir is set by the engine argv;
the host unit needs no WorkingDirectory=.

RCA

• Mechanism. writeSystemdUnitConfig passed
  deploykit.ResolveWorkingDir(...) (the in-container path) as
  EngineUnitRequest.WorkingDir; unit_emit renders it as systemd's
  WorkingDirectory=, a HOST-side CHDIR.
• Missed control. The systemd-unit path had never been exercised live: the
  podman quadlet path ignores this field, and no unit test pinned that the host
  unit must not receive a container path.
• Blast radius. Every engine: containerd pod deploy: the unit is written,
  charly start returns 0 (systemd start is async), and the container never
  appears; the failure surfaces only as a start-limit-hit later.
• Root fix. Omit WorkingDirectory= from the host unit (the container
  workdir is the engine argv's -w). Fixed in the plugin-deploy-pod PR on
  branch feat/pod-engine-selector, with the live bed as the regression
  witness.

Agent: containerd-crabbox-program/engine
Assisted-by: Claude Code ollama-cloud/deepseek-v4.1-flash:cloud (analysed on a live system)