Show the model and mode the session has, not the ones it was asked for

Picking either from the phone wrote the choice straight into the
session's state and then sent the request. Asking and having are
different things, and the difference is not rare: `auto` is a permission
mode the CLI accepts on the command line, silently resolves to
`default`, and refuses outright over the control channel -- "auto mode
unavailable for this model" -- so a session spawned in auto was in
default and one switched to auto stayed where it was, with the phone
reporting auto in both cases.

So the drivers report what they are set to and the manager follows that.
Measured, because the confirmations are not uniform: a model change
answers success with no value, so what was asked is remembered until the
answer arrives; a mode change echoes the mode it became, and that answer
wins over the request; and `init` names both -- resolving `haiku` to
claude-haiku-4-5-20251001 -- which also covers a session adopted from a
terminal that set them outside this app. A driver that cannot change
either already says so with an error, and now that error is the whole
story rather than a note beside a display that changed anyway.

The config keeps the requested value, deliberately: that answers a
different question, which is what to launch this session with next time.

Two things fall out. Control request ids are random rather than the
clock, because two in the same second shared an id and something now
looks them up. And the phone shortens a resolved name for the button --
`haiku-4-5` -- since the full one is what the CLI reports and roughly
twice the room that row has once Stop is in it.

server/src/session/driver.rs

@@ -127,6 +127,25 @@ pub enum Event {
     Status {
         state: SessionStatus,
     },
+    /// What the session is set to, as the session itself reports it.
+    ///
+    /// Asking for a change and having one are different things, and only
+    /// this one is a measurement: a model name the dialect does not know,
+    /// a mode it refuses, or a driver whose model is fixed at startup all
+    /// leave a request that was sent and nothing that changed. Reporting
+    /// from the request instead put the answer on the phone before the
+    /// question had been answered, and left it there when the answer was
+    /// no.
+    ///
+    /// Either field alone, because the two are confirmed separately and
+    /// by different things -- the CLI echoes a mode change, and names the
+    /// model it resolved an alias to when a session starts.
+    Settings {
+        #[serde(default, skip_serializing_if = "Option::is_none")]
+        model: Option<String>,
+        #[serde(default, skip_serializing_if = "Option::is_none")]
+        permission_mode: Option<String>,
+    },
     /// Per-turn token counts, where the dialect reports them.
     UsageDelta {
         tokens: u64,
@@ -206,6 +225,13 @@ pub trait Driver: Send + Sync {
     /// spawn-only: the answer changes with what is being done, and a phone
     /// is the worst place to answer "may I run this?" forty times.
     fn set_permission_mode(&self, mode: &str);
+    // Both of the above are requests, and neither reports the outcome by
+    // returning. A driver that actually changes the setting owes an
+    // [`Event::Settings`] once it has -- that event, and not the request,
+    // is what the manager and the phone read. One that cannot change it
+    // owes an [`Event::Error`] saying why; saying nothing leaves a phone
+    // showing a setting nobody applied.
+
     /// pi: native compaction; claude: `/compact`.
     fn compact(&self);
     /// Stop attending to the process but leave it running, because this