feat(init): decouple venv from install_dir; fail loud if no venv exists

The systemd unit templates hardcoded {{ install_dir }}/venv/bin/decnet.
On production hosts enroll_bootstrap.sh creates exactly that path so it
worked. On dev boxes where the operator runs `sudo decnet init` against
a source checkout with a differently-named venv (.venv, .311, .312),
every decnet-*.service looped forever in auto-restart with:

  Failed at step EXEC spawning .../venv/bin/decnet: No such file or
  directory

Templates now use {{ venv_dir }} as an independent Jinja2 var. `decnet
init` adds --venv-dir (explicit override), otherwise autodetects:

  1. $VIRTUAL_ENV (only when inside --install-dir, so a user-home venv
     never gets baked into a root-owned unit),
  2. {install_dir}/venv (production default; what enroll_bootstrap
     creates),
  3. {install_dir}/{.venv,.311,.312,.313} (common dev conventions).

Init aborts before any file writes if nothing resolves — an
operator-friendly error beats journalctl spam on every unit restart.

python3-venv doesn't set a persistent system variable — $VIRTUAL_ENV
lives in the activated shell only — so this has to be decided + baked
in at init time; there's no way for systemd to "inherit the current
venv" at unit start.

Test mode (--prefix) skips venv validation so the existing test suite
doesn't need to stub up a venv tree per case.

deploy/decnet-forwarder.service.j2

@@ -15,7 +15,7 @@ EnvironmentFile=-{{ install_dir }}/.env.local
 # Replace <master-host> with the master's LAN address or hostname. The agent
 # cert bundle at /etc/decnet/agent is reused — the forwarder presents the same
 # worker identity when it connects to the master's listener.
-ExecStart={{ install_dir }}/venv/bin/decnet forwarder \
+ExecStart={{ venv_dir }}/bin/decnet forwarder \
     --log-file /var/log/decnet/decnet.log \
     --master-host ${DECNET_SWARM_MASTER_HOST} \
     --master-port 6514 \