Let a command run in the background instead of being killed

An agent command is one blocking conn.run over a per-call connection, killed the
moment it hits its timeout -- so a ten-minute apt install is impossible, which is
exactly what a user hit. This is the substrate for running it detached instead:
the model can ask for background=true, or a command that outlasts its timeout is
kept running rather than killed, and either way the model gets tools to read and
stop it. Opt-in, off by default, under Admin -> Agents; off is byte-for-byte the
old behaviour.

The mechanism has to survive the connection closing (that is the whole premise
of the per-call model), so a job is a setsid-detached process on the far side,
redirected to a remote logfile and an exit-file; LLeMbas reconnects, as always,
to read it later. services/agent/jobs.py holds the wrappers.

Three things in those wrappers are load-bearing and each was got wrong in the
first sketch:

- The command never touches a quoted shell context. sh -c '<cmd>' shatters the
  instant the command contains a quote -- git commit -m 'fix', awk '{…}', sed
  's/…/…/' are the common case, and it is an injection hole besides. So the
  command is base64-encoded in Python and decoded on the far side into a script
  file; it is bytes, never shell syntax.
- The child records its own pid via $$ as its first act, under setsid where it
  is the session leader, so job_stop can kill the whole process group. echo $!
  from the launcher captures the wrong pid.
- The command's exit status comes from the exit-file, never the wrapper's own
  status -- which is ~0 from its trailing rm. Reading the wrapper's status would
  mark every job a success.

A command that finishes in time is indistinguishable from a foreground one --
same output, same wording; the difference shows only when it does not, where
instead of "stopped after Ns" it becomes a job id. Auto-convert is its own
sub-switch: with it off, a timeout stays a hard stop and nothing is left
running, because routing the plain case through the detached wrapper would leave
an orphan running past a stop an administrator asked for.

New agent tools job_output/job_list/job_stop, offered only when the feature is
on (the plan_submit gating pattern); job_stop is RISK_EXECUTE since it kills a
process. A job's files are namespaced by the calling chat's id and the wrappers
are always built from it, so a model in one chat cannot even name another's job.

Tested against a real local /bin/sh rather than the fake echo-the-command sshd
fixture, because the shell logic -- setsid, base64, the wait loop, the child
surviving the wait being cut off -- is the whole of the risk. The auto-wake that
prompts the model back when a job finishes is the next commit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/lembas/web/templates/admin/agents.html

@@ -124,6 +124,61 @@
     </div>
   </section>
 
+  <section class="card">
+    <h2 class="card__title">Background commands</h2>
+    <p class="card__lede">
+      A command that would outlast its timeout can be left running instead of
+      killed — detached on the far side, checked on later. It is how a long
+      install, build or download becomes possible at all.
+    </p>
+    <div class="field">
+      <label class="checkbox">
+        <input type="checkbox" name="background_enabled"
+               {{ 'checked' if values.background_enabled }}>
+        <span>Allow commands to run in the background</span>
+      </label>
+      <p class="field__hint">
+        Off means byte-for-byte the old behaviour: a command that hits its
+        timeout is killed. On, a command can be launched detached (or kept
+        running when it times out), writing to a file under
+        <code>/tmp</code> on the machine, and the model gets tools to read and
+        stop it. A detached command's log can grow without bound on the host —
+        that is the host's to contain, as with everything an agent runs there.
+      </p>
+    </div>
+    <div class="field">
+      <label class="checkbox">
+        <input type="checkbox" name="background_on_timeout"
+               {{ 'checked' if values.background_on_timeout }}>
+        <span>Keep a timed-out command running instead of killing it</span>
+      </label>
+      <p class="field__hint">
+        Off leaves the timeout a hard stop; the model can still choose to
+        background a command up front.
+      </p>
+    </div>
+    <div class="field">
+      <label class="checkbox">
+        <input type="checkbox" name="background_notify"
+               {{ 'checked' if values.background_notify }}>
+        <span>Wake the model when a background job finishes</span>
+      </label>
+      <p class="field__hint">
+        On, a finished job starts (or joins) a reply carrying its result. Off,
+        the model only sees it the next time it runs of its own accord.
+      </p>
+    </div>
+    <div class="field">
+      <label class="field__label" for="background_max_jobs">Most jobs watched at once</label>
+      <input class="input" id="background_max_jobs" name="background_max_jobs"
+             value="{{ values.background_max_jobs }}" inputmode="numeric">
+      <p class="field__hint">
+        Each is a periodic reconnect to the machine. Jobs past this still run;
+        they are simply not watched, and the model is not woken for them.
+      </p>
+    </div>
+  </section>
+
   <section class="card">
     <h2 class="card__title">What one reply may spend</h2>
     <p class="field__hint">