Make the permission mode the picker offers actually selectable

The session screen's mode picker listed `bypassPermissions`, and on any
session not born in it, choosing it failed:

    Cannot set permission mode to bypassPermissions because the session
    was not launched with --dangerously-skip-permissions

The CLI is asymmetric about that mode and it is not obvious. It will
launch straight into it on `--permission-mode` alone -- so spawning into
it from the phone has always worked -- but it refuses to switch into it
afterwards unless the process was started with the flag. So the picker
offered a state the session could not reach, and the failure arrived
after the fact as an error line in the transcript.

Sessions now launch with `--allow-dangerously-skip-permissions`, which
makes that mode reachable without selecting it: the session still starts
in whatever mode it was asked for and only moves when somebody moves it.
Deliberately the `--allow-` form; `--dangerously-skip-permissions` is the
one that turns bypassing on for everything, which would take the choice
away from whoever is holding the phone. Since the mode was already
reachable at spawn, this withholds nothing new -- it makes the two routes
to it agree.

Measured both ways round against 2.1.237, driving the control request
directly: without the flag the response is `subtype: error` with the
message above, with it `subtype: success, mode: bypassPermissions`. Then
through the app's own route on a session spawned `manual`, whose argv
reads `--permission-mode manual … --allow-dangerously-skip-permissions`
and which reported `permissionMode: bypassPermissions` when asked to
change.

server/src/session/claude.rs

@@ -360,6 +360,31 @@ impl ClaudeDriver {
             None => push("--name", &meta.title),
         }
         args.push("--include-partial-messages".to_string());
+        // Makes `bypassPermissions` *reachable*, without selecting it: the
+        // session still starts in whatever mode was asked for above, and
+        // only moves if somebody moves it.
+        //
+        // Here because the CLI is asymmetric about that mode, which is not
+        // obvious and cost a confused bug report. It will *launch* in
+        // `bypassPermissions` on the strength of `--permission-mode` alone
+        // -- so spawning straight into it from the phone has always worked
+        // -- but it refuses to *switch* into it later:
+        //
+        //     Cannot set permission mode to bypassPermissions because the
+        //     session was not launched with --dangerously-skip-permissions
+        //
+        // So the phone's own mode picker offered a mode that could not be
+        // picked, on every session it had not been given at birth. Since
+        // the mode is already reachable at spawn, this grants nothing that
+        // was being withheld; it makes the two routes to it agree.
+        //
+        // Measured against 2.1.237, both ways round: without this flag the
+        // control request comes back `subtype: error` with the message
+        // above, and with it `subtype: success, mode: bypassPermissions`.
+        // Note it is the `--allow-` form -- `--dangerously-skip-permissions`
+        // is the one that turns it on for everything, and that would take
+        // the choice away from whoever is holding the phone.
+        args.push("--allow-dangerously-skip-permissions".to_string());
 
         // Fresh logs, because the offsets that index them start at zero
         // and everything the previous process said is already in the